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Version: 
Proj ect : 



System : 
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SFB 340/B4 (Hinrichs/Gerdemann) 
Universit "at T"ubingen 
Kleine Wilhelmstr. 113 
72074 Tuebingen 
Germany 

ALE 1.0 (release 1 May 1993) under Sicstus 2 . 1 #9 



This file contains an ALE grammar covering the phenomena of aux-flip and 
partial verb-phrase topicalization in the three sentence types of German: 
verb first (VI), verb second (V2) , and verb last (VL) . Except for a few 
cases noted in the paper documenting this grammar, it closely follows 
the analyses proposed in: 

Erhard Hinrichs and Tsuneko Nakazawa 
''Partial-VP and Split-NP Topicalization in German'' 
"- An HPSG Analysis -" 



''Linearizing Finite Aux in German Complex VPs' 



You are welcome to try out the grammar. The code is available via 
anonymous ftp to "sns2.sfs.nphil.uni-tuebingen.de". The directory 
SFB/IMPLEMENTING contains the grammar including the test sentences, 
a file with some small extensions to ALE needed to run the tests, 
and a postscript version of the paper "On Implementing an HPSG theory" 
which documents the reasoning behind the grammar. If for some reason 
you are unable to retrieve the files, please contact the author at the 
address above . 



Notational conventions : 

a) variable names : only the first letter is capitalized 

b) macros: - macros without suffix are (generally) of type sign, 

- suffix _y on a macro name is used for synsem macros 

- suffix _lex on a macro name is used for sign macros 
which are intended to abbreviate lexical entries 

- suffix _arg is used on certain variables which are 
place-holders for the arguments passed to the 
macros. The problem is caused by the fact that these 
argument place-holders in ALE are no real feature structure 
variables. Several occurrences of this variable 

in a macro definition are *not* interpreted as 
reentrancy ! These _arg "variables" therefore have 
to be conjoined to a real variable in the body of 
the macro, which then can be used to note 
structure sharing . 



% Signature 

% ******************** 

•/, ################### 
% I. "Non-Linguistic" 
•/, ################### 



bot sub [bool , list , set , sign , synsem_or_nothing , loc , cat , val , 
head , case , decl , pf orm , vf orm , marking , cont , index , per , num , gend , 
qf psoa, sem_det , conx, nonloc , nonlocl , const _s true , lr] . 



°/o I. "System Types" 

% ================ 



bool sub [minus , 
minus sub [] . 
plus sub [] . 



plus] . 



list sub [ne_list , quant_list , synsem_list , sign_list , lr_list] . 
ne_list sub [ne_quant_list , 
ne_synsem_list , 
ne_sign_list , 
ne_lr_list] 
intro [hd : bot , 

tl:list] . 

quant_list sub [e_list, ne_quant_list] . 
e_list sub [] . 
ne_quant_list sub [] 

intro [hd : quant , 

tl : quant_list] . 
synsem_list sub [e_list , ne_synsem_list] . 
ne_synsem_list sub [] 

intro [hd : synsem , 

tl : synsem_list] . 
sign_list sub [ne_sign_list , n_sign_list , all_sign_list] . 
ne_sign_list sub [ne_n_sign_list , ne_all_sign_list] 
intro [hd : sign, 

tl : sign_list] . 
n_sign_list sub [e_list , ne_n_sign_list] . 
ne_n_sign_list sub [] 

intro [hd : n_s ign , 

tl : n_sign_list] . 
all_sign_list sub [e_list , ne_all_sign_list] . 
ne_all_sign_list sub [] . 
lr_list sub [e_list, ne_lr_list] . 
ne_lr_list sub [] 

intro [hd: lr, 

tl:lr_list] . 



set sub [neset , set_loc , set_npro , set_psoa, set_quant , set_ref , set _s ign] . 
eset sub [] . 

neset sub [neset _loc , neset_npro , neset _psoa, neset _quant , 
neset_ref , neset_sign] 
intro [elt : bot , els : set] . 
set_loc sub [eset, neset_loc] . 
neset_loc sub [] 

intro [elt : loc , els : set_loc] . 



:1766I 8nv I£ XA9xo80^6/Sl-drao:ATXJB: 



set_npro sub [eset , neset_npro] . 
neset_npro sub [] 

intro [elt:npro, els : set_npro] . 
set_psoa sub [eset, neset_psoa] . 
neset_psoa sub [] 

intro [elt:psoa, els : set_psoa] . 
set_quant sub [eset, neset_quant] . 
neset_quant sub [] 

intro [elt : quant , els : set_quant] . 
set_ref sub [eset, neset_ref] . 
neset.ref sub [] 

intro [elt:ref, els : set_ref ] . 
set_sign sub [eset, neset_sign] . 
neset_sign sub [] 

intro [elt:sign, els : set_sign] . 



X ################ 
X II. "Linguistic" 
X ################ 



X7. BEGIN — sign 



'/, sign bears an additional lr feature for debugging 
*/, to store the list of lexical rules applied 

sign sub [lex_sign, phrase, n_sign, non_n_sign] 
intro [synsem : synsem , 

qstore : set_quant , 
retr : quant_list , 
lr:lr_list] . 

lex_sign sub [word, lex_phrase, n_lex_sign, non„n_lex_sign] 
intro [retr: e_list] . 
word sub [n_word, non_n_word] . 
n_word sub [] . 
non_n_word sub [] . 
lex_phrase sub [n_lex_phrase , non_n_lex_phrase] . 
n_lex_phrase sub [] . 
non_n_lex_phrase sub [] . 
n_lex_sign sub [n_word, n_lex_phrase] . 
non_n_lex_sign sub [non_n_word, non_n_lex_phrase] . 
phrase sub [lex_phrase , struc_phrase , n_phrase , non_n_phrase] . 
struc_phrase sub [n_struc_phrase , non_n_struc_phrase] 
intro [dtrs : const_struc] . 
n_struc_phrase sub [] . 
non_n_struc_phrase sub [] . 
n_phrase sub [n_lex_phrase , n_struc_phrase] . 
non_n_phrase sub [non_n_lex_phrase , non_n_struc_phrase] . 
n_sign sub [n_lex_sign, n_phrase] 

intro [synsem :n_synsem] . 
non_n_sign sub [non_n_lex_sign, non_n_phrase] 
intro [synsem :non_n_synsem] . 



7,7.7, BEGIN synsem 



synsem_or_nothing sub [synsem, nothing] . 
synsem sub [n_synsem, non_n_ synsem] 
intro [loc:loc, 

nonloc :nonloc] . 
n_synsem sub [] 

intro [loc:n_loc] . 
non_n_ synsem sub [] 



iii 



intro [loc : non_n_loc] . 

nothing sub [] . 

7X/.7. BEGIN — loc — 

loc sub [n_loc, non_n_loc] 
intro [cat: cat, 

conx : conx , 
cont : cont] . 
n_loc sub [] 

intro [cat:n_cat] . 
non_n_loc sub [] 

intro [cat :non„n_cat] . 



7.7.7.7.7, BEGIN — cat — 

cat sub [n_cat, non_n_cat] 
intro [val: val, 

head: head, 
marking : marking , 
npcomp:bool] . 
n_cat sub [] 

intro [head: noun] . 
non_n_cat sub [] 

intro [head:non_noun] . 

7.7.7.7.7.7. BEGIN — val — 

val sub [] 

intro [spr: sign.list, 
subj : sign_list, 
comps : sign_list] . 

7.7.7.7.7.7. END val — 

X7.X7.X7. BEGIN — head — 

X Notes on the subtypes of head: 

X - adj_noun_det and adj_or_noun are included as type only to 

X satisfy the feature intro condition 

X and introduce case and decl for ad j , noun, det 

X - the introduction of noun and non_noun 

X needed for n_sign_list, which is used to constrain 

X on the raisable arguments of auxiliaries, leads 

X to quite an explosion of the hierarchy: 

X beside the complication of the sign (!), synsem, and cat 
X definitions , it necessitates the types adj _prep_verb 
X adj_or_det, and non_noun to be introduced here (to 
X get a lattice and satisfy the fic) 

X - the HPSGII subtype reltvzr is not needed in this grammar 

X - prepositions are not in the fragment either, but 

X are included for easier extension. No pforms are specified. 

head sub [func, subst, adj_noun_det , non_noun] . 
func sub [det, marker] 

intro [spec : synsem] . 
det sub [] . 
marker sub [] . 
subst sub [adj _or_noun , adj _prep_verb] 
intro [prd:bool, 

mod: synsem_or_nothing] . 



iv 



adj_or_noun sub [adj, noun], 
adj sub [] 

intro [mod: synsem] . 
noun sub [] . 
adj _prep_verb sub [adj , prep, verb] . 
prep sub [] 

intro [pf orm:pf orm] . 
verb sub [f in_v,n_f in_v] 
intro [aux:bool, 
inv : bool , 
fliprbool, 
vf orm:vf orm] . 
fin_v sub [] 

intro [vf orm: fin] . 
n_fin_v sub [] 

intro [inv : minus , 

vform:n_f in] . 
adj_noun_det sub [adj_or_noun, adj_or_det] 
intro [case: case, 
decl : decl] . 
adj_or_det sub [adj.det] . 
non_noun sub [f unc , adj _or_det , adj _prep_verb] . 

case sub [nom, n_nom] . 
nom sub [] . 

n_nom sub [acc, dat, gen] . 
acc sub [] . 
dat sub [] . 
gen sub [] . 

decl sub [wk, st] . 
wk sub [] . 
st sub [] . 

pf orm sub [] . 

vform sub [fin, n_fin] . 
fin sub [] . 
n_fin sub [bse, psp] . 
bse sub [] . 
psp sub [] . 

%%%%% END — head — 
'/.'/.*/.■/.'/. BEGIN — marking — 

*/, no conjunctions are specified, since not in fragment 

marking sub [marked, unmarked] . 
marked sub [comp, conj] . 
comp sub [dass , ob] . 
dass sub [] . 
ob sub [] . 
conj sub [] . 
unmarked sub [] . 

n°/.n END marking 

%%%% END — cat — 

'/,y y,y. begin — cont — 

cont sub [nom_obj , psoa, quant] . 
nom_ob j sub [npro , pron] 

intro [index : index , 



V 



restr : set_psoa] . 

npro sub [] . 
pron sub [ana, ppro] . 
ana sub [recp, refl] . 
recp sub [] . 
refl sub [] . 
ppro sub [] . 
psoa sub [] 

intro [quants : quant_list , 
nucl : qf psoa] . 

quant sub [] 

intro [det : sem_det , 

restind:npro] . 

"/XT/. BEGIN — Cnom-obj) index — 

index sub [ref , expl_es] 
intro [per: per, 
num : num , 
gend:gend] . 
ref sub [] . 
expl_es sub [] . 

per sub [first, second, third] . 
first sub [] . 
second sub [] . 
third sub [] . 



num sub [plur, sing], 
plur sub [] . 
sing sub [] . 

gend sub [fem, masc, neutr] . 
fern sub [] . 
masc sub [] . 
neutr sub [] . 

y.yX/7. END Cnom-obj) index 

'/X/X/. BEGIN (psoa) qfpsoa 



qfpsoa sub [prop, un_rel, bin_rel, tern_rel] . 

prop sub [table , relative , man, book, poem, student , daughter, story, 
snake , father , water , letter , karl , anna , sarah , peter , 
good , green , small] 
intro [inst: ref]. 
table sub [] . 
relative sub [] . 
man sub [] . 
book sub [] . 
poem sub [] . 
student sub [] . 
daughter sub [] . 
story sub [] . 
snake sub [] . 
father sub [] . 
water sub [] . 
letter sub [] . 
karl sub [] . 
peter sub [] . 
anna sub [] . 
sarah sub [] . 
good sub [] . 



vi 



green sub [] . 
small sub [] . 
un_rel sub [laugh, auxiliary] . 
laugh sub [] 

intro [laugher :ref] . 
auxiliary sub [have, will, can, must, want] 
intro [arg:psoa], 
have sub [] . 
will sub [] . 
can sub [] . 
must sub [] . 
want sub [] . 
bin_rel sub [love, read, find], 
read sub [] 

intro [reader : ref , 
read:ref ] . 

love sub [] 

intro [lover: ref, 
loved: ref] . 

find sub [] 

intro [finder : ref , 
found: ref] . 
tern_rel sub [give, tell], 
give sub [] 

intro [giver : ref , 

receiver : ref , 
given:ref] . 

tell sub [] 

intro [teller : ref , 
tellee :ref , 
told: ref] . 

7.7.7.7.7. END Cpsoa) qfpsoa 

7.7.7.7.7. BEGIN (quant) sem_det 

sem_det sub [neg_indef ,def , indef ] . 
neg_indef sub [] . 
def sub [] . 
indef sub [] . 

'/X/.7.7. END (quant) sem_det 

7.7.7.7. END — cont — 
7.7.7.7. BEGIN — conx — 

7. Notes on conx: 

7. - no context handling is done in the fragment 
V, - name anchoring is done in content instead 
V, - to include conx in the fragment 
7, c_inds has to be declared subtype of bot 

conx sub [] . 

7c intro [backgr: set_psoa, 

7c c_inds: c_inds] . 
7. 

7. c_inds sub [] . 

'/, intro [addressee : ref , 

7. speaker: ref, 

*/, utt_loc:ref] . 



7.7.7.7. END — conx — 
7.7.7. END — loc — 



7.7.7. BEGIN — nonloc — 
7, Notes on nonloc 1 : 

7. - slash is the only relevant nonlocal feature for this grammar. 
7, Therefore que and rel are not specified as appropriate. 

nonloc sub [] 

intro [inherited : nonloc 1 , 
to_bind:nonlocl] . 

nonlocl sub [] 

intro [ 7. que:set_npro, 

7, rel:set_ref, 
slash: sign^list] . 

7.7.7. END nonloc 

7.7. END synsem 

7.7. BEGIN const_struc 

const_struc sub [coord^struc , headed_struc] . 
coord_struc sub [] . 

headed_struc sub [adjunct_head, comp_struc , filler_head, marker_head, spr_head] 
intro [head_dtr : sign] . 
adjunct_head sub [] 

intro [adjunct_dtr : sign] . 
comp_struc sub [head_comp , head_subj _comp] 
intro [comp_dtrs : sign_list] . 
head_comp sub [hcil ,hci2 ,hci3 , 

hcnil , hcni2 , hcni3 , 
vcf ,vcnf] . 
hcil sub [] . hci2 sub [] . hci3 sub [] . 
hcnil sub [] . hcni2 sub [] . hcni3 sub [] . 
vcf sub [] . vcnf sub [] . vci sub [] . 
head_subj_comp sub [hscil ,hsci2 ,hsci3 ,hsci4, 
hscnil ,hscni2a,hscni2b, 
hscni3a,hscni3b,hscni4a,hscni4b] 
intro [subj_dtr : sign] . 
hscil sub [] . hsci2 sub [] . hsci3 sub [] . hsci4 sub [] . 
hscnil sub [] . hscni2a sub [] . hscni2b sub [] . 

hscni3a sub [] . hscni3b sub [] . hscni4a sub [] . hscni4b sub [] . 
filler_head sub [] 

intro [f iller_dtr:sign] . 
marker_head sub [] 

intro [marker_dtr : sign] . 
spr_head sub [] 

intro [spr_dtr : sign] . 

7.7. END const_struc 

7. lexical rule names as subtype of lr (for debugging) 
lr sub [ein2kein, bse_to_3_sing, bse_to_3_plur , bse_to_psp, 
bse_to_subst_bse, celr, selr, pvpelr, obj_order_lr] . 

ein2kein sub [] . bse_to_3_sing sub [] . bse_to_3_plur sub [] . 
bse_to_psp sub [] . bse_to_subst_bse sub [] . celr sub [] . 
selr sub [] . pvpelr sub [] . obj_order_lr sub [] . 

7. END sign 



viii 



7, 
'/. 
7, 



****************************************************** 
Macros 

****************************************************** 



*/, ########################### 

I. simple abbreviations 
7. a) path : value 
7. b) path:parameter passed 
X ########################### 



x ========================= 

'/, 1. macros for system stuff 



'/, abbreviation for singleton sets : 
sset(X) macro (Celt: X), 

(els: eset)) . 



'/„ abbreviation for normal sets: 
set(E,F) macro (Celt: E) , 

(els: F)). 



% ============================== 

7, 1. macros for linguistic types 



% 

% macros of type < const_struc > 
% 



% dtrs filled: 



adjunct_head_cs(Adj ,Head) 

macro ( (adjunct_dtr : Adj ) , 

(head.dtr: Head) ) . 



filler_head_cs (Filler , Head) 

macro ( (f iller_dtr : Filler), 
(head.dtr: Head) ) . 



marker_head_cs (Marker , Head) 

macro ( (marker_dtr : Marker), 
(head.dtr: Head) ) . 



spr_head_cs (Spr , Head) 

macro ((spr_dtr: Spr) , 

(head.dtr: Head)) . 



head_comp_cs (Subtype , Head , Comps) 

macro (Subtype, (head_dtr: Head) , 

(comp_dtrs: Comps)) . 

head_sub j _comp_cs (Subtype , Head, Sub j , Comps) 

macro (Subtype, (head_dtr: Head), 
(subj_dtr: Subj) , 
(comp_dtrs: Comps)) . 

for testing: macros with dtrs not filled 
7. adjunct_head_cs(_,_) macro adjunct_head_cs 

7« f iller_head_cs(_,_) macro f iller_head_cs . 

'/, marker_head_cs (_ , _) macro marker_head_cs . 

7« spr_head_cs (_ , _) macro spr_head_cs . 



ix 



'/„ head_comp_cs(Subtype,_,_) macro (head_comp_cs , Subtype). 

'/„ head_subj_comp_cs (Subtype , _,_,_) macro (head_subj _comp_cs , Subtype). 

y a 

7, macros of type < sign > 

• /o 

7. 

'/» apply to all signs 
7. 



head(X) 


macro 


(synsem: 


@head_y(X)) . 










noun 


macro 


(synsem: 


@noun_y) . 


adj 


macro 


(synsem: 


@adj_y) . 








@det y) 


prep 


macro 


(synsem: 


@prep_y) . 


marker 


macro 


(synsem: 


@marker_y) . 


val(X) 


macro 


(synsem: 


@val_y(X)) . 


val_subj (X) 


macro 


(synsem: 


@val_subj_y(X)) . 


val spr(X) 






@val spr y (X) ) 


val_comps (X) 


macro 


(synsem: 


@val_comps_y(X) ) 


subj_sat 


macro 


(synsem: 


@subj_sat_y) . 










comps _ sat 


macro 


(synsem: 


@comps_sat_y) . 


sat 


macro 


(synsem: 


@sat_y) . 


cont (X) 




(synsem : 


@cont y(X)) . 


conz(X) 


macro 


(synsem: 


@conx_y(X)) . 


marking (X) 


macro 


(synsem: 


@marking_y(X)) . 


unmarked 


macro 


(synsem: 


@unmarked_y) . 


inherited(X) 


macro 


(synsem: 


@inherited_y(X)) 


to_bind(X) 


macro 


(synsem: 


@to_bind_y(X)) . 


in_slash(X) 


macro 


(synsem: 


@in_slash_y(X)) . 


to_slash(X) 


macro 


(synsem: 


@to_slash_y(X)) . 


no_in_slash 


macro 


(synsem: 


@no_in_slash_y) . 


no_to_slash 


macro 


(synsem: 


@no_to_slash_y) . 


no_slash 


macro 


(synsem: 


@no_slash_y) . 


npcomp(X) 


macro 


(synsem: 


@npcomp_y(X)) . 


minus _npcomp 


macro 


(synsem: 


Ominus _npc omp_y ) 


plus_npcomp 


macro 


(synsem: 


@plus_npcomp_y) . 


no_lr 


macro 


(lr: []) 




% 

7t relevant 

7. 


:or < noun >, < adj >, < det > 


decl(X) 


macro 


(synsem: 


@decl_y(X)) . 


St 


macro 


(synsem: 


@st_y) . 


wk 


macro 


(synsem: 


@wk„y) . 



X 



7. 

'/, relevant 

7 


for < func > 




spec(X) 


macro (synsem: 


<§spec_y(X)) . 


7. 

7 relevant 

7 


for < det > 




restind(X) 


macro (synsem: 


@restind_y(X)) 


7 

7 relevant 

7 


for < subst > 




mod(X) 
no_mod 


macro (synsem: 
macro (synsem: 


<3mod_y(X)) . 
@no_mod_y) . 


prd(X) 
minus _prd 
plus_prd 


macro (synsem: 
macro (synsem: 
macro (synsem: 


<3prd_y(X)). 
@minus_prd_y) . 
@plus_prd_y) . 


7 

relevant 
7 


for < noun > 





index (X) 


macro 


(synsem: 


<§index_y(X)) . 


restr(X) 


macro 


(synsem: 


@restr_y(X)) . 


per(X) 


macro 


(synsem: 


@per_y(X)) . 


first 


macro 


(synsem: 


Of irst_y) . 


second 


macro 


(synsem: 


@second_y) . 


third 


macro 


(synsem: 


<§third_y) . 


num(X) 


macro 


(synsem: 


@num_y (X) ) . 


sing 


macro 


(synsem: 


<§sing_y) . 


plur 


macro 


(synsem: 


@plur_y) . 


third_sing 


macro 


(synsem: 


@third_sing_y) 


third_plur 


macro 


(synsem: 


@third_plur_y) 


gend(X) 


macro 


(synsem: 


<3gend_y(X)) . 


masc 


macro 


(synsem: 


@masc_y) . 


f em 


macro 


(synsem: 


@f em_y) . 


neutr 


macro 


(synsem: 


<9neutr_y) . 


case(X) 


macro 


(synsem: 


@case_y(X)) . 


nom 


macro 


(synsem: 


@nom_y) . 


acc 


macro 


(synsem: 


@acc_y) . 


dat 


macro 


(synsem: 


Qdat.y) . 


gen 


macro 


(synsem: 


@gen_y) . 


7 

7 relevant 

7 


for < verbs > 




vf orm(X) 


macro 


(synsem: 


@vf orm_y(X) ) . 


fin 


macro 


(synsem: 


Of in_y) . 


bse 


macro 


(synsem: 


@bse_y) . 


psp 


macro 


(synsem: 


@psp_y) . 


n_f in 


macro 


(synsem: 


@n_f in_y) . 



aux(X) 


macro 


(synsem: 


@aux_y(X)) . 


minus _aux 


macro 


(synsem: 


@minus_aux_y) . 


plus_aux 


macro 


(synsem: 


@plus_aux_y) . 


inv(X) 


macro 


(synsem: 


@inv_y(X)) . 


minus _inv 


macro 


(synsem: 


@minus_inv_y) . 


plus_inv 


macro 


(synsem: 


@plus_inv_y) . 


flip(X) 


macro 


(synsem: 


@flip_y(X)) . 


minus.flip 


macro 


(synsem: 


@minus_f lip_y) 


plus_f lip 


macro 


(synsem: 


@plus_f lip_y) . 



> /t 

7 macros of type < synsem > 
y t 



% ■ 

7 apply to all synsems 
7 ■ 



head_y(X) macro (loc : cat :head: X) . 

verb_y macro @head_y (verb) . 

noun_y macro @head_y(noun) . 

adj_y macro @head_y (adj ) . 

det_y macro @head_y (det) . 

prep_y macro @head_y (prep) . 

marker_y macro @head_y (marker) . 



val_y(X) macro (loc : cat : val : X) . 

val_subj_y(X) macro @val_y(subj :X) . 

val_spr_y(X) macro @val_y(spr:X) . 

val_comps_y (X) macro @val_y (comps : X) . 



sub j _sat_y macro @val_sub j _y ( [] ) . 

spr_sat_y macro @val_spr_y( [] ) . 

comps_sat_y macro @val_comps_y ( [] ) . 

sat^y macro (@subj_sat_y, @spr_sat_y, @comps_sat_y) . 



cont_y(X) macro (loc : cont : X) . 

conx_y(X) macro (loc : conx : X) . 



marking_y(X) macro 

unmarked_y macro 

inherited_y (X) macro 

to_bind_y(X) macro 

in_slash_y(X) macro 

to_slash_y(X) macro 

no_in_slash_y macro 

no_to_slash_y macro 

no_slash_y macro 



(loc: cat: marking :X) . 
@marking_y (unmarked) . 

(nonloc : inherited: X) . 
(nonloc :to_bind: X) . 

@inherited_y(slash:X) . 
@to_bind_y(slash:X) . 

@inherited_y(slash: [] ) . 
@to_bind_y(slash: [] ) . 
(@no_in_slash_y , 
@no_to_slash_y) . 



npcomp_y(X) macro (loc : cat : npcomp : X) . 

minus_npcomp_y macro @npcomp_y (minus) . 

plus_npcomp_y macro @npcomp_y(plus) . 
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x 

X relevant for < noun >, < adj >, < det > 
% 

decl_y(X) macro @head_y(decl:X) . 

st_y macro @decl_y(st) . 

wk_y macro @decl_y(wk) . 

'/, 

X relevant for < func > 

7. 

spec_y(X) macro @head_y (spec : X) . 

7. 

'/, relevant for < det > 

7, 

restind_y(X) macro @cont_y (restind : X) . 

7. 

X relevant for < subst > 

X 



mod_y (X) 
no_mod_y 

prd_y(X) 
minus _prd_y 
plus_prd_y 

X 



macro @head_y(mod:X) . 
macro @mod_y (nothing) . 

macro @head_y(prd:X) . 
macro @prd_y (minus) . 
macro @prd_y(plus) . 



X relevant for < noun > 



index_y (X) 


macro 


restr_y(X) 


macro 


per_y(X) 


macro 


f irst_y 


macro 


second_y 


macro 


third_y 


macro 


num^y (X) 


macro 


sing_y 


macro 


plur_y 


macro 


third_sing_y 


macro 


third_plur_y 


macro 


gend_y(X) 


macro 


masc_y 


macro 


f em_y 


macro 


neutr_y 


macro 


case_y(X) 


macro 


nom_y 


macro 


acc_y 


macro 


dat_y 


macro 


gen_y 


macro 



per_y(second) . 



7. 

To relevant for 

7. 


< verb > 




vf orm_y(X) 


macro 


@head_y (vf orm : X) 


fin_y 


macro 


@vf orm_y (f in) . 


bse_y 


macro 


@vf orm_y (bse) . 


P s P-y 


macro 


@vf orm_y(psp) . 


n_f in_y 


macro 


@vf orm_y(n_f in) . 


aux_y(X) 


macro 


@head_y(aux:X) . 


minus _aux_y 


macro 


@aux_y (minus) . 


plus_aux_y 


macro 


@aux_y(plus) . 


inv_y (X) 


macro 


@head_y(inv:X) . 


minus _ inv^y 


macro 


@inv_y (minus) . 


plus_inv_y 


macro 


@inv_y (plus) . 


flip_y(X) 


macro 


@head_y(f lip:X) . 


minus_f lip_y 


macro 


@f lip_y(minus) . 


plus_f lip_y 


macro 


Of lip_y(plus) . 



I ########################################## 

7, II. linguistically motivated abbreviations 
% ########################################## 

7. ;;;;;;; 
To general 
7. ;;;;;;; 



7 < sign > 
x_null_s 
x_bar_s 
xp 

X < synsem > 

xp_y 



macro word, 
macro phrase . 

macro (phrase, (synsem: @xp_y)) . 



macro @comps_sat_y . 



% * adjectives * 

X < synsem > 
ap_y macro (@adj_y, ©sat_y) . 

X * determiners * 



X < sign > 
dp 

X < synsem > 

dp_y 



macro (phrase, (synsem: @dp_y)) . 
macro (@det_y, @sat_y) . 



X * noun 

X ;;;;;;; 



X < sign > 



macro (sign, (synsem: @n_y) ) . 



xiii 



xiv 



n_bar macro (phrase , (synsem: @n_bar_y) ) . 

np macro (phrase, (synsem: @np_y) ) . 

np(Index.Case) macro (Onp, ©index(Index) , ©case (Case) ) . 

n_cont(Prop) macro (synsem: On_cont_y(Prop)) . 



sub j _np 
obj_np 



macro (Onp , 
macro (Onp, @case( n_nom )) . 



*/, < synsem > 

n_bar_y 
np^y 

n_cont_y 
n_cont_y (Prop) 



macro (Onoun_y, @subj_sat_y) . 

macro (On_y, @comps_sat_y) . 

macro (Qn_y, @comps_sat_y, Ospr_sat_y) . 

macro @cont_y(nom_obj) . 

macro @cont_y( ((index: Index) , 

(restr : ©sset (( (quants : [] ) , 

(nucl: (prop, Prop, 

(inst: Index)))))))). 



'/„ * prepositions * 

% < synsem > 
p_y macro (Oprep_y, @no_mod_y) . 

7. ;;;;;;;;; 

7 * verbs * 

7. ;;;;;;;;; 

7. < sign > 

v macro (synsem: Ov_y) . 

v (Vf orm , Sem , Sub j , Comps , Flip) 

macro (synsem: (@v_y, Ov_cont_y (Sem) , 

©Vf orm_y(Vf orm) , Of lip.y (Flip) , 
@val__subj_y(Subj) , @val_comps_y (Comps) ) ) . 



v_null 

v_null(Vform) 

v_bar 

vp 

s 

s_bar 

main_v 
aux_v 

v_cont 
v_cont (X) 
v_nucl(X) 



macro (word, Ov) . 

macro (Ov.mill, Ovf orm(Vf orm) ) . 

macro (phrase, @v) . 



macro (phrase, (synsem 
macro (phrase, (synsem 
macro (phrase, (synsem 



©vp_y) ) . 
Os_y)) . 
Os_bar_y) ) . 



macro (synsem: Omain_v_y) . 
macro (synsem: Qaux_v_y) . 



macro (synsem 
macro (synsem 
macro (synsem 



Ov_cont_y) . 
Ov_cont_y(X)) . 
Ov_nucl_y(X)) . 



f in_v (Per , Num , S_Sub j , Comps) 

macro (synsem: Of in_v_y (Per , Num, S_Subj , Comps) ) . 



7. < synsem > 

v_y 

v P-y 

s -y 

s_bar_y 



macro (Overb_y, @v_cont_y, Ospr_sat_y) . 

macro (Ov_y, @comps_sat_y) . 

macro (Ov_y, @sat_y) . 

macro (Ov_y , @sat_y , ©marking_y (marked) ) . 
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main_v_y macro (Ov_y, @minus_aux_y) . 

aux_v_y macro (Ov_y, @plus_aux_y) . 

aux_v_y(Vf orm) macro (Oaux_v_y, Ovform_y(Vform)) . 

v_cont_y macro (Ocont_y( (psoa, (quants: [])))) . 

% Qconx_y ( (backgr : eset) ) ) . 

v_cont_y(Cont) macro (Ov_cont_y, @cont_y (Cont) ) . 

v_nucl_y(Nucl) macro (Ov_cont_y, @cont_y((nucl: Nucl))). 

% Note on fin_v: 

7o fin_v enforces a singleton list subj value! 

7 This is incorrect for real raising verbs, which don't enforce 
% the existence of a subject: e.g. "mich scheint zu frieren" 

f in_v_y (Per , Num , S_Sub j , Comps) 

macro (Ohead_y(f in_v) , 
Of in^y , 

Oval_subj_y( [ (S_Subj ,0noun,0nom,0per(Per) , 

©num (Num) ) ] ) , 

Oval_comps_y (Comps) ) . 

n_f in_v_y (Vf orm, Subj , Comps) 

macro (Ohead_y(n_f in_v) , Qvform_y( (Vform, n_fin) ), 
Oval_subj_y(Subj ) , @val_comps_y(Comps)) . 

7. Note on arg_raising_vp_compl : 

71 The "n_sign_list" restriction on the raised arguments deserves some 
7c notice. As can be seen in the hierarchy, the introduction of that 

7. type causes a flood of new types, some of which have to be introduced 

*/, to keep the hierarchy a lattice (no multiple mgus) and satisfy the 

7. fic. The alternative idea to put the restriction into the phrase 

7. structure rules, in which auxiliaries construct, works (cleanly) only 

7t via a specification on the mother of the vc rules, which keeps verbal 

7c complements from getting passed on. This is linguistically correct, 

7c since no verbs subcategorize for two verbal complements and one always 

7c gets realized in the vc schema. Note that head-subj -comps and 

7c head-comps rules always realize all complements. However this 

7c technique cannot keep a finite auxiliary from directly combining with 

"/ t two verbal complements, one of which was raised. Therefore the 

*/. "n_sign_list" seems to be the best solution (even though it screws up 

7c the hierarchy as noted) . 

arg_raising_vp_compl_y(Vp_vf orm, Vp_f lip) 

macro (Qv_nucl_y( (arg:Vp_sem) ), 
Oval_subj_y(Subj ) , 

Oval_comps_y ( [(@v(Vp_vform, Vp_sem, Subj, 

Vp_comps , Vp_f lip) , Ominus_npc 
I (Vp_comps, n_sign_list)] )). 



% ###################################### 
7c III. macros to specify lexical entries 
% ###################################### 



7, ;;;;;;; 
7c general 

7c Note on all_lex: 

7c in_ slash is empty, to_ slash is not specified 

7c i.e finite intransitive verbs can immediately combine with filler 
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all_lex(S) macro (word, (synsem: (S, @no_in_slash_y , @minus_npcomp_y) ) , 

@no_lr) . 

det_lexl(S) macro (@all_lex(S) , ©unmarked). 

mark_lexl(S) macro (@all_lex(S) , (qstore: eset)). 

7 Note on subst_lex: 

°/ Since so far no predicative constructions are treated in this fragment, 
7, minus_prd is included for all substantive entries. 

subst_lex(S) macro (@all_lex(S) , ©unmarked, Cqstore: eset), ©minus _prd) . 

7 Note on no_mod_lex: 

7 In this fragment the only elements which can modify, are adjectives. 

7 Therefore all other substantial elements should use the no_mod_lex macro. 

no_mod„lex(S) macro (@subst_lex(S) , @no_mod) . 

7 * adjectives * 

wk_adj _lex (Prop , Case , Gend , Num , Prd) macro @adj _lex (Prop , Case , Gend , Num , Prd , wk , st ) . 

st.adj _lex (Prop , Case , Gend , Num , Prd) macro @adj _lex (Prop , Case , Gend , Num , Prd , st , wk) . 

adj_lex(Prop, Case_arg, Gend, Num, Prd, Adj_decl ,Det_decl) 
macro (@subst_lex( (@adj_y, 
@sat_y , 

@case_y( (Case, Case_arg) ) , 

@gend_y (Gend) , 

@third_y, 

@num_y(Num) , 

@prd_y(Prd) , 

@decl_y(Adj_decl) , 

@mod_y( (@noun_y, @case_y (Case) , 

@subj_sat_y , @comps_sat_y , 
@val_spr_y( [(synsem: (@det_y, @sat_y, 

<§decl_y(Det_decl)))] ) , 
@index_y(I) , @restr_y(N_restr) ) ), 

@index_y(I) , 

@restr_y(@set( ((quants: []),(nucl: (Prop, (inst:I)))), 
N_restr))))) . 

7. ;;;;;;;;;;;;;; 

7 * determiner * 

det_lex2 (Case_arg, Gend, Num, Decl) 
macro @det_lexl( (@det_y, 

@case_y( (Case, Case_arg) ), 
@decl_y(Decl) , 

@spec_y( (@noun_y, @case_y (Case) , @cont_y(N_cont) , 
@subj _sat _y , @comps_sat_y , 
@val_spr_y([(@det, @sat)])) ), 

@sat_y, 

©cont_y( (quant , 

(restind: (npro, N_cont, 

(index : ( (per : third) , 
(num : Num) , 

(gend:Gend))))))))). 
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det_lex (Sem_det , Case , Gend , Num , Decl) 

macro (@det_lex2 (Case , Gend, Num, Decl) , 

@cont( (Cont, (det : Sem_det ) ) ), 
(qstore : @sset (Cont) ) ) . 

'/, * markers * 
mark_lex(M) 

macro @mark_lexl( (@marker_y, @marking_y (M) , @sat_y, 
@spec_y( (@verb_y, @fin_y, @sat_y, 
@unmarked_y) ) ) ) . 

'/. ;;;;;;;;; 

°/ ( * nouns * 

l ;;;;;;;;; 

°/ Notes on lexical hierarchy macros for nouns 

°/o - n_lexl specifies information common to all nouns 

'/, - To accommodate the exceptional character of np_lex 

'/, it does not inherit from all_lex (the general lex hierarchy) . However 
7, n_lex inheriting from n_lexl also inherits from the general hierarchy 
7. via no_mod_lex. 

7c information common to all nominal lexical entries 
n_lexl macro (Snoun, @subj_sat , @comps_sat , @per (third) ) . 

'/, noun with declension class specification 
n_lex (Case , Num , Gend , Prop , Det_decl) 
macro (@n_lexl , 

@case (Case) , 

@val_spr([ (@det, Osat, ©case(Case)) ]), 
@no_mod_lex( (@case_y (Case) , 

©val_spr_y([ @decl(Det_decl) ]), 

@n_cont_y (Prop) , 

@num_y(Num) , 

@gend_y(Gend)))) . 

7, noun without declension class specification 
n_indif _lex (Case , Num , Gend , Prop) 

macro @n_lex (Case , Num , Gend , Prop , _) . 

7 Notes on np_lex: 

7. The following two macros are not inheriting from a sub-macro of all„lex 
7. - np_lex is exceptional in two ways: its type is lex_phrase, and 
7. it has a nonempty qstore . 

7. 

% -> All non-colliding specifications of the general lexical hierarchy 
% (relevant for nouns is no_mod_lex) are specified by hand. 
% -> The noun specific properties are specified via using n_lexl . 

np_lex (Prop , Case , Gend) macro 

% standard no_mod_lex without word and qstore specification: 

(@no_in_slash, @minus_npcomp , ©unmarked, @minus_prd, @no_mod, 
% standard noun: 
@n_lexl, 
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7, extra: 

lex_phrase , 
@n_cont (Prop) , 
@sat, 

@num(sing) , @gend(Gend) , @case(Case) , 
@cont (Cont) , 

(qstore: @sset( C(det:def), (restind: Cont ) ) )), 
Cretr: [] ) ) . 



'/, * verbs * 

7 ;;;;;;;;; 

7 Note on the specification of verbal entries: 

'/, Only bse verbs need to be specified. Finite and psp forms are 
7 obtained via lexical rules. 

7. 

'/, a) auxiliaries 

7. 

7 Properties of auxiliaries: 

7 1. subcategorization frame of a vp embedding verb 
7 2. obligatory argument raising 
7 3. subject-raising 
7 

7 Note concerning raising: 

7 aux_lex enforces a singleton list subj value! 

7 This is incorrect for real raising verbs, which don't enforce 

*/, the existence of a subject. 

7 

7 Note concerning aux-flip: 

7 No flip values are specified here, since bse auxs flip optionally. 

7 Haben und werden are specified as inheriting the flip value of 

*/, its complement (to allow double flip, e.g. wird haben kommen koennen) 

'/ ( via specifying flip sharing in addition to aux_lex in aux_f lip_id_lex . 

7 The lexical rules forming finite and psp verbs then demand minus_f lip, 

7 and remove possibly existing flip reentrancies . 

aux_lex(Qf psoa, Vp_vf orm) 

macro @no_mod_lex( (@head_y (n_f in_v) , @aux_v_y(bse) , 
@v_nucl_y(Qfpsoa) , 

@arg_raising_vp_compl_y (Vp_vf orm,.) )) . 

aux_f lip_id_lex(Q.f psoa, Vp_vf orm) 

macro @no_mod_lex( (@head_y (n_f in_v) , @aux_v_y(bse) , 
@v_nucl_y (Qf psoa) , 
@flip_y(Flip) , 

@arg_raising_vp_compl_y (Vp_vf orm, Flip) ) ) . 

7. 

7, b) main verbs 

V. 

intrans_lex (Nucl ,10) 

macro @main_v_lexl (Nucl , @n_f in_v_y (bse , [@np(I0,_)], [] ) ) . 
trans.lex(Nucl,IO,Il,Cl) 

macro @main_v_lexl (Nucl , @n_f in_v_y Cbse , [@np(I0,_)], 

Wnp(Il,Cl)])) . 

ditrans.lex (Nucl , 10 , I 1 , CI , 12 , C2) 

macro @main_v_lexl (Nucl , @n_f in_v_y (bse , [@np(I0,_)], 

[®np(I2,C2) , 8np(Il,Cl)])) . 
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7. 

7 auxiliary macros 

7 

7 Note on main_v_lexl: 

7 Main verbs are all specified to be minus_flip. 
7 < sign > 

main_v_lexl (N , S) macro @no_mod_lex( (S , @main_v_y , @v_nucl_y (N) , @minus_f lip_y) ) . 



7 Lexicon 

'/ e ****************************** 

y 

7 ad j ect ives : [wk/st] _ad j _lex (Prop , Case , Gend , Num , Prd) 
y 



7 weak: 



kleinen 


> 


@wk_adj 


_lex(small, 


dat, 




sing, 


minus) 


kleinen 


> 


@wk_adj 


_lex(small, 






plur , 


minus) 


kleinen 


> 


@wk_adj 


_lex(small, 


acc, 


masc, 


sing, 


minus) 


kleine 


— > 


@wk_adj 


_lex (small, 


nom, 


f em, 


sing, 


minus) 


kleine 


— > 


@wk_adj 


_lex(small, 


acc, 


f em, 


sing, 


minus) 


kleine 


— > 


@wk_adj 


_lex (small , 


nom, 


masc , 


sing, 


minus) 


kleine 


> 


@wk_adj 


„lex(small, 


nom, 


neutr , 


sing, 


minus) 


kleine 


> 


@wk_adj 


_lex(small, 


acc, 


neutr , 


sing, 


minus) 


7 strong 
















kleinen 


> 


@st_adj 


_lex (small , 


acc, 


masc , 


sing, 


minus) 


kleinen 


> 


@st_adj 


_lex (small , 


dat, 




plur , 


minus) 


kleine 


> 


@st_adj 


_lex(small, 


nom, 


f em, 


sing, 


minus) 


kleine 


> 


@st_adj 


_lex(small, 


acc, 


f em, 


sing, 


minus) 


kleine 


> 


@st_adj 


_lex(small, 


nom, 




plur, 


minus) 


kleine 


— > 


@st_adj 


_lex (small, 


acc, 




plur, 


minus) 


kleines 


— > 


@st_adj 


_lex(small, 


nom, 


neutr , 


sing, 


minus) 


kleines 


— > 


@st_adj 


_lex(small, 


acc , 


neutr , 


sing, 


minus) 


kleiner 


> 


@st_adj 


_lex (small , 


dat, 


f em, 


sing, 


minus) 


kleiner 


> 


@st_adj 


_lex(small, 


nom, 


masc , 


sing, 


minus) 


kleinem 


> 


@st_adj 


_lex(small, 


dat, 


(masc;neutr) , 


sing, 


minus) 



7 weak: 



gute 


— > 


@wk_ad j _lex (good , 


nom, 




sing, 


minus) 


gut en 


— > 


@wk_ad j _lex (good , 


acc , 


masc , 


sing, 


minus) 


gute 


— > 


@wk_ad j _lex (good , 


acc , (f e 


n;neutr) ,sing, 


minus) 


gut en 


— > 


@wk_ad j _lex (good , 


dat, 




sing, 


minus) 


gut en 


— > 


@wk_ad j _lex (good , 






plur, 


minus) 


*/, strong: 












guter 


— > 


@st_adj_lex(good, 


nom, 


masc, 


sing, 


minus) 


gute 


— > 


@st_adj_lex(good, 


nom, 


fern, 


sing, 


minus) 


gutes 


— > 


@st_adj_lex(good, 


nom, 


neutr 


sing, 


minus) 


gut en 


— > 


@st_adj_lex(good, 


acc , 


masc, 


sing, 


minus) 


gute 


— > 


@st_adj_lex(good, 


acc , 


fern, 


sing, 


minus) 


gutes 


— > 


@st_adj_lex(good, 


acc , 


neutr 


sing, 


minus) 


gut en 


— > 


@st_adj_lex(good, 


dat, 




sing, 


minus) 


gute 


— > 


@st_adj_lex(good, 


nom, 




plur , 


minus) 


gute 


— > 


@st_adj_lex(good, 


acc , 




plur , 


minus) 



XX 



guten > @st_adj_lex(good, dat , _, plur, minus). 



■ /( 

'/, determiners 

% 

V, 1 . definite (all strong) 



der > @det_lex(def , nom, masc, sing, st) . 

die > @det_lex(def , nom, fem, sing, st) . 

die > @det_lex(def , acc, fem, sing, st) . 

das > @det_lex(def , nom, neutr, sing, st) . 

das > @det_lex(def , acc, neutr, sing, st) . 

den > @det_lex(def , acc, masc, sing, st) . 

dem > @det_lex(def , dat, (masc;neutr) , sing, st) . 

der > @det_lex(def , dat, fem, sing, st) . 

die > @det_lex(def , nom, _, plur, st) . 

den > @det_lex(def , dat, _, plur, st) . 

die > @det_lex(def , acc, _, plur, st) . 



2. indefinite 



'/, a) strong (not needed in PVP fragment) 



'/, b) weak 



7. i. singular: can undergo 



ein > @det_lex(indef , 

eine > @det_lex (indef , 

eine > @det_lex (indef , 

einen > @det_lex (indef , 

ein > @det_lex (indef , 

einem > @det_lex (indef , 

einer > @det_lex (indef , 



.ndef _wk_det_lr and empty_ein_lr 

nom, (masc;neutr) , sing, wk) . 

nom, fem, sing, wk) . 

acc, fem, sing, wk) . 

acc, masc, sing, wk) . 
acc, neutr, sing, wk) . 

dat, (masc ; neutr) , sing, wk) . 
dat, fem, sing, wk) . 



7« ii. plural: can undergo indef _wk_det_lr 

einige > @det_lex (indef , nom, _, plur, wk) . 

einiger > @det_lex (indef , gen, _, plur, wk) . 

einige > @det_lex (indef , acc, _, plur, wk) . 

einigen > @det_lex (indef , dat, _, plur, wk) . 



y t 

7, marker: mark_lex (Marking) 
y t 



dass > @mark_lex(dass) . 



% 

7, nouns: n_lex(Case,Num,Gend,Prop,Det_decl) (Det_decl optional) 
% 



mann > @n_indif_lex 

mann > @n_indif_lex 

mann > @n_indif_lex 

maenner > @n_indif_lex 



( nom, sing, masc, man ). 

( acc, sing, masc, man ). 

( dat, sing, masc, man ). 

( nom, plur, masc, man ). 
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maennern 


> 


On 


indif 


.lex( 


acc, 


plur, 


masc, 


man ) . 


maennern 


> 


Sn 


indif 


.lex( 


dat, 


plur, 


masc, 


man ) . 


tisch 


> 


Sn 


indif 


.lex( 


nom, 


sing, 


masc, 


table 


tisch 


> 


@n 


indif 


.lex( 


acc , 


sing, 


masc, 


table 


tisch 


> 


@n 


indif 


.lex( 


dat, 


sing, 


masc, 


table 


tische 


> 


On 


indif 


.lex( 


nom , 


plur, 


masc, 


table 


tische 


> 


@n 


indif 


.lex( 


acc, 


plur, 


masc, 


table 


tischen 


> 


Sn 


indif 


.lex( 


dat, 


plur, 


masc, 


table 


buch 


> 


Sn 


indif 


.lex( 


nom, 


sing, 


neutr , 


book ) 


buch 


> 


@n 


indif 


.lex( 


acc , 


sing, 


neutr , 


book ) 


buch 


> 


On 


indif 


.lex( 


dat, 


sing, 


neutr , 


book ) 


buecher 


> 


@n 


indif 


.lex( 


nom, 


plur , 


neutr, 


book ) 


buecher 


> 


@n_ 


indif 


.lex( 


acc, 


plur, 


neutr, 


book ) 


buechern 


> 


@n 


indif 


.lex( 


dat, 


plur, 


neutr, 


book ) 


geschichte 


> 


@n 


indif 


.lex( 




sing, 


fem, 


story- 


geschichten 


> 


@n 


indif 


.lex( 




plur, 


fem, 


story 



7c nouns showing strong and weak forms: 
*/. 

masc 

> @n_lex( nom, sing, masc 

> @n_lex( acc 



verwandte 
verwandten 
verwandten 
verwandten 



relative , st ) . 
relative , st ) . 
@n_lex( dat, sing, masc, relative, st ). 
Sn_lex( _, plur, (masc;fem), relative, st ). 



sing, masc, 



verwandte r 


> 


@n_lex( 


nom, 


sing, 


masc , 


relative, 


wk ) 


verwandten 


> 


@n_lex( 


acc, 


sing, 


masc, 


relative, 


wk ) 


verwandten 


> 


@n_lex( 


dat, 


sing, 


masc, 


relative, 


wk ) 


verwandte 


> 


@n„lex( 


nom, 


plur , 


(masc 


; fem) , relative 


verwandte 


> 


@n„lex( 


acc, 


plur, 


(masc 


;fem) , relative 


verwandten 


> 


@n_lex( 


dat, 


plur, 


(masc 


;fem) , relative 


7o fem 
















verwandte 


> 


@n„lex( 


nom, 


sing, 


fem, 


relative , 


st ) 


verwandte 


> 


@n„lex( 


acc, 


sing, 


fem, 


relative , 


st ) 


verwandten 


> 


@n_lex( 


dat, 


sing, 


fem, 


relative , 


st ) 


% fem plur 


= masc plur 












verwandte 


> 


@n_lex( 


nom, 


sing, 


fem, 


relative , 


wk ) 


verwandte 


> 


@n_lex( 


acc, 


sing, 


fem, 


relative , 


wk ) 


verwandten 


> 


@n„lex( 


dat, 


sing, 


fem, 


relative, 


wk ) 


% fem plur 
•/ 


= ma 


c plur 













% proper name nps 

7. 



karl > @np_lex(karl, (nom;dat ; acc) , masc). 

peter > @np_lex (peter , (nom; dat ; acc) , masc) . 

anna > @np_lex (anna, (nom; dat ; acc) , fem) . 

sarah > @np_lex (sarah, (nom; dat ; acc) , fem) . 

To be able to test nps with case without having to 
7. build them first: 



karlN > @np_lex (karl , nom, masc) . 

karlD > @np_lex (karl , dat, masc) . 

karlA > @np_lex (karl , acc, masc) . 
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peterN 


> 


@np 


lex (peter , 


nom, 


masc 


peterD 


> 


@np 


lex (peter , 


dat, 


masc 


peterA 


> 


@np 


lex (peter , 


acc, 


masc 


annaN 


> 


@np 


lex (anna, 


nom, 


f em) 


annaD 


> 


@np 


lex (anna, 


dat, 


f em) 


annaA 


> 


@np 


lex (anna, 


acc , 


f em) 


sarahN 


> 


@np 


lex(sarah, 


nom, 


f em) 


sarahD 


> 


@np 


lex(sarah, 


dat, 


f em) 


sarahA 


> 


@np 


lex(sarah, 


acc, 


f em) 



'/, 

°/c main_verbs 
'/, 



'/, intransitive 
lachen > @intrans_lex ( (laugh, (laugher : X) ) , X ). 

°/ transitive 

lieben > @trans_lex( (love , (lover : X) , (loved:Y)), X, Y, acc ). 

finden > @trans_lex( (find, (finder :X) , (found: Y) ) , X, Y, acc ). 

lesen > @trans_lex( (read, (reader : X) , (read: Y) ) , X, Y, acc ). 

'/, ditransitive 

geben > @ditrans_lex ( (give , (giver : X) , (receiver : Y) , (given: Z) ) , 

Y, dat, Z, acc ) . 

erzaehlen — > Qditrans.lex ( (tell , (teller : X) , (tellee :Y) , (told: Z) ) , X 
Y, dat, Z, acc ) . 

'/, database: v_entry (bse , 3 . sing, 3 .plur , (l=sein/2=haben) , psp) 

v_entry (lachen, lacht , lachen, 2 , gelacht ) . 

v_entry (lieben, liebt , lieben, 2 , geliebt ) . 

v_entry (f inden , f indet , f inden , 2 , gef linden) . 

v_entry(lesen, liest , lesen, 2, gelesen) . 

v_entry (geben, gibt, geben, 2, gegeben) . 

v_entry(erzaehlen, erzaehlt , erzaehlen, 2, erzaehlt) . 



'/, 

°/c auxiliaries 
'/. 



'/, aux_lex(Q.f psoa, Vp_vform) 

haben > @aux_f lip_id_lex (have , psp) . 

werden > @aux_f lip_id_lex (will ,bse) . 

koennen > @aux_lex(can,bse) . 

muessen > @aux_lex(imist,bse) . 

wollen > @aux_lex(want,bse) . 



'/, database: v_entry (bse ,3 . sing, 3 .plur , (l=sein/2=haben) , psp) 



V 


.entry (haben, 


hat, 


haben , 


2, 


gehabt) . 


V 


.entry (werden , 


wird, 


werden, 


1, 


geworden) 


v 


.entry (koennen, 


kann, 


koennen, 


2, 


gekonnt) . 


v 


.entry(muessen, 


muss, 


muessen, 


2, 


gemusst) . 


V 


.entry (wollen, 


will, 


wollen, 


2, 


gewollt) . 
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°/„ Lexical Rules 
'/ 

% Each rule only applies once. If several applications would have been 
% necessary, the recursion was put into the def clauses attached: e.g. 
% several complements are extracted via celr in one application, using 
'/„ a call to power_list. 

:- lex_rule_depth(5) . '/„ any specification > will do 

7, ###################################################### 

I. Morphological rules 

7, ###################################################### 

y- ====================================== 

7o 1. Simple morphological rules 
•/„======================================= 

°/ applies to: all indefinite determiners with semantic contribution 
'/„ action: introduces negative indefinite 
7o note : 

7o All ''ein'' lexical entries, except those with no semantic 
°/ contribution (empty qstore) have a corresponding negative 
°/ indefinite entry. 

ein2kein lex_rule 

(In, @cont( (det:indef) ), (qstore: neset) ) 

**> 

(Out, @cont( (det :neg_indef ) )) 

if 

passO( (In, (lr: L)), 

(Out, (lr: [ein2kein I L ]))) 

morphs 

(einig.X) becomes (kein,X) , 
ein becomes kein, 

(eine,X) becomes (keine.X). 

%======================================= 

°/ 2. Morphological with syntactic effect 
y- ====================================== 

y a 

% bse verbs -> fin verbs 

% 

7o applies to: bse verbs 

°/ action: introduces past participle forms for all verbs 
7o note : 

°/ Since finite verbs with more than one slash element can never 

be part of a sentence (only ditransitive *bse* verbs having slashed 
°/ both objects to occur as topicalized main verb only pvp make use 
7 of more than one slash element) they only bse verbs with no or one 
°/ slash element can undergo f initivization . This however is only 
'/„ to avoid useless lexical entries from occurring in the lexicon, not 
°/ doing so would not change the correctness of the grammar. 

I 

% a) 3rd sing: version that inserts subj before comps 

y 

bse_to_3_sing lex_rule 

(In, @bse, @val_subj ( [Subj] ) , @val_comps (Comps) , @in_slash(Slash)) 
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**> 

(Out, Oinv(Inv) , @f in_v(third,sing,Subj ,Comps)) 

if 

(max_l_list(Slash,Inv) , 
passiaCCln, Clr:LR)) , 

(Out, (lr: [bse_to_3_sing|LR])))) 

morphs 

Bse becomes Sing when 

lookup_v(Bse, Sing, _,_,_) . 

7 

b) 3rd plur: version that inserts subj before comps 
7 

bse_to_3_plur lex_rule 

(In, @bse , @val_subj ( [Subj] ) , @val_comps (Comps) , <§in_slash (Slash) ) 

**> 

(Out, @inv(Inv) , Of in_v(third, plur, Subj , Comps)) 

if 

(max_l_list (Slash, Inv) , 
passla((In, (lr :LR) ) , 

(Out, (lr: [bse_to_3_plur|LR])))) 

morphs 

Bse becomes Plur when 

lookup_v(Bse,_,Plur,_,_) . 

y t 

bse verbs -> psp verbs 
y o 

7 applies to: bse verbs 

action: introduces past participle forms for all verbs 
7 note: only past participles formed with haben 
7 are part of the fragment . 

bse_to_psp lex_rule 
(In, @bse) 

**> 

(Out, @psp, @minus_f lip) 

if 

passlb((In, (lr :LR) ) , 

(Out, (lr: [bse_to_psp|LR] ))) 

morphs 

Bse becomes Psp when 

lookup_v(Bse,_,_,2,Psp) . 

• /( 

7 bse auxiliaries -> Ersatzinf initv (= bse) 
y t 

7 applies to: bse auxiliaries 

action: introduces substitute infinitives of modals 
7 and markes them as obligatory flip triggering 

7 (= plus_flip) 

bse_to_subst_bse lex_rule 
(In, @aux_v, Obse) 

**> 

(Out, @psp, @plus_flip) 

if 

passlb((In, (lr :LR) ) , 

(Out , (lr : [bse_to_subst_bse I LR] ) ) ) 

morphs 

X becomes X. 
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7 ###################################################### 

7 II. Introducing unbounded dependencies 

7 ###################################################### 



% 

7 Complement Extraction Lexical Rule 
% 

7 applies to: bse full verbs (aux:-) 

7 action: extract any number of complements of bse verbs 
7 note : 

7 - modified to account for slash taking 

7 sign- instead of local-values 

7 - psp is obtained by bse -> psp lr 

7 - fin is obtained by bse -> fin lr 

7 Note: maximally allow slash lists of length one 

7 (cf. comment at fin lr) 

celr lex_rule 
(In, Obse, 

@minus_aux, 
@val_comps(Cl) , 
@no_in_slash) 

**> 

(Out, @val_comps(C2) , 

@in_slash( (E,ne_list) )) 

if 

(pass2((In, (lr :LR) ) , 

(Out, (lr: [celrlLR]))), 
power_list(Cl, E, C2)) 
morphs 

X becomes X. 

% 

7 Subject Extraction Lexical Rule 
% 

7 applies to: finite verbs 

7 action: extracts the subject of finite verbs 
7 note: All finite verbs with extracted subject 
7 appear in inverted constructions. 

selr lex_rule 
(In, Ofin, 

@val_subj (Subj) , 
@no_in_slash) 

**> 

(Out, @subj_sat, 

@in_slash(Subj) , 
@plus_inv) 

if 

pass2b((In, (lr :LR) ) , 

(Out, (lr: [selrlLR]))) 

morphs 

X becomes X. 
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x 

7, PVP Extraction Lexical Rule 

jj 

'/, applies to: bse aux with empty in-slashes 

'/, action: shifts valence from comps to nonlocal (see paper for details) 
'/, note : 

'/, - finites are then obtained via f initivization lex rules 

°/c - The +INV in output is only relevant for finite auxiliaries 

pvpelr lex_rule 

(In, Overb, @plus_aux, 

@bse , @no_in_slash, 
@val_comps C [ (@verb , 

@vform (Vform) , 
@val_comps (Comps) , 
@val_subj (Subj) , 
@cont (Cont) ) 
I Comps ] ) ) 

**> 

(Out, @val_comps ( (L, n_sign_list) ) , 
@in_slash ( [ (Overb , 

@vf orm(Vf orm) , 
@comps_sat , 
@val_subj (Subj) , 
@cont (Cont) , 
®in_slash(L)) ])) 

if 

Cpass2((In, (lr:LR)) , 

(Out , (lr : [pvpelr I LR] ) ) ) ) 

morphs 

X becomes X. 



7, ###################################################### 

7, III. Specials 

7, ###################################################### 

% 

Object Order Lexical Rule 
% 

7 Not used in the test examples, since of no theoretical interest 
% 

% applies to: ditransitive verbs with comps dat < acc (standard in lexicon) 
% action: orders comps acc < dat 



% thereby freeing word order of complements 

% of ditransitive verbs realized together in 

% a construction 

°/,obj_order_lr lex_rule 

*/, (In, @minus_aux, 

7. @bse , 

7. @val_comps( [(A,@np,@dat) , (B , <§np, Oacc)] ) ) 



7.**> 

7. (Out, @val_comps C [B , A] ) ) 
7.if 

7. pass3(Cln, (lr :LR)) , 

7. (Out, (lr: [obj_order_lr|LR])))) 

7,morphs 

% X becomes X. 
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7. #################################################################### 

°/ Passing of unchanged information for all lexical rules: 

% #################################################################### 

% 

I. 1) Predicates and macros for morphological lexical rules 
• /o 

°/ carrying over everything but det (of quant subtype of cont) 
°/„ note: only applies to determiners 

passO (@coreO (Qstore, Retr, Nonloc, Cat , Rest ind,Conx) , 

@coreO (Qstore , Retr , Nonloc , Cat , Rest ind , Conx) ) if true . 

coreO (Qstore , Retr , Nonloc , Cat , Rest ind , Conx) macro 
(word, (qstore : Qstore) , 
(retr: Retr) , 

(synsem: ((nonloc: Nonloc), 
(loc: ((cat: Cat), 

(cont: restind: Restind) , 
(conx: Conx)))))) . 

% 

°/ I. 2) Predicates and macros for morphological lexical rules 
7 with syntactic effect 

% 

carrying over everything but inv, vform, flip, val_comps and val_subj 

passla (Qcorela (Qstore , Retr , Aux , Mod , Prd , Marking , Npcomp , Val_spr , Cont , Conx , Nonloc ) , 
Scorela (Qstore , Retr , Aux , Mod , Prd , Marking , Npcomp , Val_spr , Cont , Conx , Nonloc ) ) 
if true . 

corela (Qstore , Retr , Aux , Mod , Prd , Marking , Npcomp , Val_spr , Cont , Conx , Nonloc) macro 
(word, (qstore : Qstore) , 
(retr: Retr) , 
(synsem: (@aux_y(Aux) , 

@mod_y(Mod) , 

@prd_y(Prd) , 

@marking_y (Marking) , 

@npcomp_y (Npcomp) , 

@val_spr_y(Val_spr) , 

@cont_y(Cont) , 

@conx_y(Conx) , 

(nonloc : Nonloc) ) ) ) . 

% 

°/„ carrying over everything but vform and flip 

passlb (Score lb (Qstore , Retr , Aux , Inv , Mod , Prd , Marking , Npcomp , Val , Cont , Conx , Nonloc ) , 
Score lb (Qstore , Retr , Aux , Inv , Mod , Prd , Marking , Npcomp , Val , Cont , Conx , Nonloc ) ) 
if true. 

core lb (Qstore , Retr , Aux , Inv , Mod , Prd , Marking , Npcomp , Val , Cont , Conx , Nonloc) macro 
(word, (qstore : Qstore) , 
(retr: Retr) , 
(synsem: (@aux_y(Aux) , 
@inv_y(Inv) , 
@mod_y(Mod) , 
<§prd_y(Prd) , 
Omar king_y (Marking) , 
@npcomp_y (Npcomp) , 
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<§val_y(Val) , 
@cont_y(Cont) , 
@conx_y(Conx) , 
(nonloc : Nonloc) ) ) ) . 

y t 

°/c database_access : lookup_v(bse ,3 . sing, 3 .plur ,psp_aux_nr , psp) 
°/c to convert atoms (easier to write lexicon entries) 
°/c to lists (wanted by ALE) 

lookup_v (Bse , Sing , Plur , Aux , Psp) : - 

v_entry (Bse 1 , Singl , Plur 1 , Aux , Pspl ) , 
explode (Bsel , Bse) , 
explode (Singl , Sing) , 
explode (Plur 1, Plur) , 
explode (Pspl, Psp) . 

y t 

'/, III. Predicates and macros for udc introducing lexical rules 

y t 

°/c pass everything, but comps and in_slash 

pass2 (@core2(Qst ore ,Retr , Head, Marking, Npcomp, Val_subj ,Val_spr,Cont ,Conx,To_bind) , 
@core2 (Qstore , Retr , Head , Marking , Npcomp , Val_sub j , Val_spr , Cont , Conx , To_bind) ) 
if true . 

core2 (Qstore, Retr , Head, Marking, Npcomp, Val_subj , Val_spr, Cont , Conx, To_bind) macro 
(word, (qstore: qstore) , 
(retr: Retr) , 
(synsem: (@head_y(Head) , 

@marking_y (Marking) , 

@npcomp_y (Npcomp) , 

@val_subj_y(Val_subj) , 

@val_spr_y (Val_spr) , 

@cont_y(Cont) , 

@conx_y(Conx) , 

@to_bind_y (To.bind) ) ) ) . 

'/„ pass everything, but subj and in_slash 

pass2b (@core2b (Qstore , Retr , Head , Marking , Npcomp , Val_comps , Val_spr , Cont , Conx , To_bind) , 
@core2b (Qstore , Retr , Head , Marking , Npcomp , Val_comps , Val_spr , Cont , Conx , To_bind) ) 
if true. 

core2b (Qstore , Retr , Head , Marking , Npcomp , Val_comps , Val_spr , Cont , Conx , To_bind) macro 
(word, (qstore: Qstore), 
(retr: Retr) , 
(synsem: (@head_y(Head) , 

<3marking_y (Marking) , 

@npcomp_y (Npcomp) , 

@val_comps_y(Val_comps) , 

@val_spr_y(Val_spr) , 

@cont_y(Cont) , 

@conx_y(Conx) , 

@to_bind_y (To.bind) ) ) ) . 
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% 

% IV. Predicates and macros for word order freeing lexical rules 
% 

% everything but the comps value stays the same 

pass3 (@core3 (Qstore , Retr , Aux , Flip , Inv , Mod , Prd , Vf orm , Marking , Npcomp , 
Val_subj , Val_spr, Cont , Conx, Nonloc) , 
@core3 (Qstore , Retr , Aux , Flip , Inv , Mod , Prd , Vf orm , Marking , Npcomp , 
Val_subj ,Val_spr, Cont , Conx, Nonloc) ) if true. 

core3 (Qstore , Retr , Aux , Flip , Inv , Mod , Prd , Vf orm , Marking , Npcomp , 
Val_subj ,Val_spr, Cont, Conx, Nonloc) macro 
(word, (qstore: Qstore), 
(retr: Retr) , 
(synsem: (@aux_y(Aux) , 

@flip_y(Flip) , 

@inv_y(Inv) , 

@mod_y(Mod) , 

@prd_y(Prd) , 

@vf orm_y(Vf orm) , 

Omar king_y (Marking) , 

@npcomp_y (Npcomp) , 

@val_subj_y(Val_subj) , 

<§val_spr_y(Val_spr) , 

@cont_y(Cont) , 

@conx_y(Conx) , 

(nonloc : Nonloc) ) ) ) . 



*/ 

% Phrase Structure Rules 

7, *************************************************************** 

°/„ General notes on ps rules: 

% - Principles applying to all rules are fed via the clause: 

% principles (Mother, Syntactic_Head, Semantic_Head, List_of _Dtrs , Marking_Dtr) 

% Marking_Dtr is the marker, if there is one, else the head 

% - Order on Comps List: <most oblique element ... least oblique element> 

% - Subject (least oblique np) is encoded in 

% - subj attribute, or 

% - extracted (only possible for finite verbs) 

1=================================================== 

°/ (1) head subj complement 

1=================================================== 

% 

°/ finite sentences (inverted, or non-inverted) 
y a 

% 

% a) inverted 
% 

% intransitive verb + subj 
% aux + subj (vpelr aux) 
hsc_plus_invl rule 

(Mother, @hsc_mother) ===> 

cat> (Head, ©hsc_head( [S] , [] ) , <§plus_inv) , 
cat> (S, @subj_np), 

goal> hsc_goal(hscil, Mother, Head, S, [] ) . 
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7. transitive verb + obj + subj 
'/ ( aux + vc + subj 
7. aux + objl + subj (vpelr aux) 
hsc_plus_inv2 rule 

(Mother, @hsc_mother) ===> 

cat> (Head, @hsc„head( [S] , [C] ) , @plus_inv) , 
cat> (S, @subj_np), 
cat> C, 

goal> hsc_goal(hsci2, Mother, Head, S, [C] ) . 

'/„ ditransitive verb + objl + obj2 + subj 
7, aux + vc + obj + subj 
7, aux + objl + obj2 + subj (vpelr aux) 
hsc_plus_inv3 rule 

(Mother , @hsc_mother) ===> 

cat> (Head, @hsc_head( [S] , [C1,C2] ) , @plus_inv) , 
cat> (S, @subj_np), 
cat> (C2, @obj_np), 
cat> CI, 

goal> hsc_goal(hsci3, Mother, Head, S, [C1,C2]). 

7. aux + vc + objl + obj 2 + subj 
hsc_plus_inv4 rule 

(Mother , @hsc_mother) ===> 

cat> (Head, @hsc_head( [S] , [C1,C2,C3] ) , @plus_inv, @plus_aux) , 
cat> (S, @subj_np), 
cat> (C3, @obj_np), 
cat> (C2, @obj_np), 
cat> CI, 

goal> hsc_goal(hsci4, Mother, Head, S, [C1,C2,C3]). 

% 

% b) non-inverted 
% 

°/ intransitive verb + subj 
hsc_minus_invl rule 

(Mother, @hsc_mother) ===> 
cat> (S, @subj_np), 

cat> (Head, @hsc_head( [S] , [] ) , @minus_inv, @minus_aux) , 
goal> hsc_goal(hscnil , Mother, Head, S, [] ) . 

°/ transitive verb + obj + subj 
hsc_minus_inv2a rule 

(Mother, @hsc_mother) ===> 
cat> (S, @subj_np), 
cat> (C, @obj_np), 

cat> (Head, @hsc_head( [S] , [C] ) , @minus_inv, @minus_aux) , 
goal> hsc_goal(hscni2a, Mother, Head, S, [C] ) . 

°/ aux + vc + subj 
hsc_minus_inv2a rule 

(Mother , @hsc_mother) ===> 
cat> (S, @subj_np), 
cat> (C, @minus_flip) , 

cat> (Head, @hsc_head( [S] , [C] ) , @minus_inv, @plus_aux) , 
goal> hsc_goal(hscni2a, Mother, Head, S, [C] ) . 

aux + vc [f lip] + subj 
hsc_minus_inv2b rule 

(Mother, @hsc_mother) ===> 
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cat> (S, @subj_np), 

cat> (Head, @hsc_head( [S] , [C] ) , @minus_inv, @plus_aux) , 
cat> (C, @plus_f lip) , 

goal> hsc_goal(hscni2b, Mother, Head, S, [C] ) . 

°/ ditransitive verb + objl + obj2 + subj 
hsc_minus_inv3a rule 

(Mother , @hsc_mother) ===> 
cat> (S, @subj_np) , 
cat> (C2, @obj_np), 
cat> (CI, Onoun), 

cat> (Head, @hsc_head( [S] , [CI , C2] ) , @minus_inv, @minus_aux) , 
goal> hsc_goal(hscni3a, Mother, Head, S, [C1,C2]). 

y, aux + vc + obj + subj 
hsc_minus_inv3a rule 

(Mother, @hsc_mother) ===> 
cat> (S, @subj_np) , 
cat> (C2, @obj_np), 
cat> (CI, @minus_f lip) , 

cat> (Head, @hsc_head( [S] , [CI ,C2] ) , @minus_inv, @plus_aux) , 
goal> hsc_goal(hscni3a, Mother, Head, S, [C1,C2]). 

°/ aux + vc[flip] + obj + subj 
hsc_minus_inv3b rule 

(Mother , <§hsc_mother) ===> 
cat> (S, @subj_np), 
cat> (C2, @obj_np), 

cat> (Head, @hsc_head( [S] , [CI ,C2] ) , @minus_inv, @plus_aux) , 
cat> (CI, @plus_flip), 

goal> hsc_goal(hscni3b, Mother, Head, S, [C1,C2]). 

aux + vc + objl + obj 2 + subj 
hsc_minus_inv4a rule 

(Mother , @hsc_mother) ===> 
cat> (S, @subj_np), 
cat> (C3, Oobj.np), 
cat> (C2, @obj_np), 
cat> (CI, @minus_f lip) , 

cat> (Head, @hsc_head( [S] , [CI ,C2,C3] ) , Sminus.inv, @plus_aux) , 
goal> hsc_goal(hscni4a, Mother, Head, S, [C1,C2,C3]). 

°/ aux + vc[flip] + objl + obj 2 + subj 
hsc_minus_inv4b rule 

(Mother, @hsc_mother) ===> 
cat> (S, @subj_np), 
cat> (C3, @obj_np), 
cat> (C2, @obj_np), 

cat> (Head, @hsc_head( [S] , [CI ,C2,C3] ) , @minus_inv, @plus_aux) , 
cat> (CI, @plus_flip), 

goal> hsc_goal(hscni4b, Mother, Head, S, [C1,C2,C3]). 



7. 

7« hsc core 

7o 



hsc^mother macro (phrase, @plus_npcomp, @sat) . 

hsc_head(S,C) macro (word, @verb, @fin, 

@val_subj (S) , @spr_sat , @val_comps (C) , 

@no_to_slash) . 
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hsc_goal (Subtype, Mother, Head, Subj , Comps) if 

dtrs(Mother, @head_subj _comp_cs (Subtype , Head, Subj , Comps)) , 
principles(Mother, Head, Head, [Head, Subj I Comps], Head). 



(2) head complement 
1=================================================== 

y t 

°/o (A) Verbal complex construction 
°/c = aux(n_fin) + vc 
X 

% (vc + aux_n_f in) 

% Note: Subj and inherited arguments are passed up. 
vc_minus_f lip rule 

(Mother, @vc_mother (S ,Rest ) ) ===> 
cat> (C, @vc_comp, @minus_f lip) , 
cat> (Head, Overhead (S , [C I Rest] ) ) , 
goal> hc_goal(vcnf , Mother, Head, [C] ) . 

% (aux_n_fin + vc[flip]) 
vc_plus_flip rule 

(Mother, @vc_mother(S,Rest) ) ===> 
cat> (Head, @vc_head(S, [C I Rest] ) ) , 
cat> (C, @vc_comp, @plus_f lip) , 
goal> hc_goal(vcf, Mother, Head, [C] ) . 

% 

(B) inverted finite sentences with extracted subject 
% 

'/, Note on verbs with extracted subj : 

% Such verbs are marked +INV by the selr. 

"j s Note on vc_plus_inv: 

"k Note that in the case of aux_fin+ vc no nominal complements are realized. 
% Nonetheless it is a he ad- complement rule and the mother bears the 
'/, specification [NPCOMPS +] . That specification is intended to mean "level 
'/, where NP elements are discharged, in case there are any to discharge" 

'/, (trans + obj) subj extracted 

% (aux_fin + vc) subj extracted 
hc_plus_invl rule 

(Mother, @hc_mother_f in) ===> 

cat> (Head, @hc_head_f in( [C] ) , @plus_inv) , 
cat> C, 

goal> hc_goal(hcil, Mother, Head, [C] ) . 

'/, (aux_fin + vc + obj) subj extracted 
'/, (ditrans + ob j 1 + obj 2) subj extracted 
hc_plus_inv2 rule 

(Mother, @hc_mother_f in) ===> 

cat> (Head, @hc_head_f in( [CI , C2] ) , @plus_inv) , 
cat> (C2, @obj_np), 
cat> CI, 

goal> hc_goal(hci2, Mother, Head, [C1,C2]). 

% (aux_fin + vc + ob j 1 + obj 2) subj extracted 
hc_plus_inv3 rule 

(Mother, @hc_mother_f in) ===> 

cat> (Head, @hc_head_f in( [CI , C2 ,C3] ) , @plus_inv, @plus_aux) , 
cat> (C3, @obj_np), 
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cat> (C2, <3obj_np), 
cat> (CI, @vc_comp) , 

goal> hc_goal(hci3, Mother, Head, [C1,C2,C3]). 



% 

% (C) non-inverted non-finite possibly partial vps (always topicalized) 
t 

% Note: The subject is never empty, since only finite verbs 

% can undergo selr and only non-finite verbs construct here. 



% 0-place verbs are topicalized as word 



*/, (verb + obj) 
% (vc + raised obj) 
hc_minus_invl rule 

(Mother, @hc_mother(S) ) ===> 
cat> (C, @obj_np), 

cat> (Head, @hc_head_n_f in(S, [C] ) , @minus_inv) , 
goal> hc_goal(hcnil, Mother, Head, [C] ) . 

(verb + objl + obj2) 
% (vc + raised objl + raised obj 2) 
hc_minus_inv2 rule 

(Mother, @hc_mother(S) ) ===> 
cat> (C2, Oobj.np), 
cat> (CI, @obj_np), 

cat> (Head, @hc_head_n_f in(S, [C1,C2] ) , @minus_inv) , 
goal> hc_goal(hcni2, Mother, Head, [C1,C2]). 



% 

% vc core 
% 



vc_mother(S,C) macro (@verb, 

©minus _npcomp , 

@val_subj (S) , @spr_sat , @val_comps (C) ) . 
vc_head(S,C) macro (word, 

@n_f in, 

<3hc_head(S,C)) . 
vc_comp macro Overb. 



% 

7, he core 
% 



hc_mother(S) macro 



hc_mother_f in macro 



(@verb, 

@comps_sat , 

@plus_npcomp , 

@val_subj (S) , @spr_sat) . 
<§hc_mother( [] ) . 



hc_head(S,C) macro (@val_subj (S) , @spr_sat , @val_comps (C) , 

@no_to_slash) . 
hc_head_n_f in(S,C) macro (@hc_head(S ,C), @n_f in) . 
hc_head_f in(C) macro (word, @hc_head( [] ,C) , @f in) . 



hc_goal (Subtype, Mother, Head, Comps) if 

dtrs (Mother , @head_comp_cs (Subtype , Head, Comps) ) , 
principles (Mother, Head, Head, [Head I Comps] , Head). 
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%— — 

(3) marker head 
y_ ================ 



marker_head rule 

(Mother, phrase, Oval(Val)) ===> 
cat> 

Marker , 
cat> 

(Head, ®minus_inv, @unmarked, @val (Val) , 
@no_to_slash) , 

goal> 

(spec_p(Head, Marker) , 

dtrs(Mother, @marker_head_cs (Marker , Head) ) , 
principles (Mother, Head, Head, [Head, Marker] .Marker)) . 

1=================================================== 

'/, (4) spr head 

1=================================================== 

°/ t Note on spr_head: 

7. Specifier and head select each other. This causes cyclic structures 

'/, to arise in the head-dtr as well as the mother of spr_head constructions! 

'/, Since ALE represents cyclic feature structures by cyclic PROLOG structures, 

'/, versions of Sicstus before 2.1 #7 and Quintus will bomb upon trying to 

7. parse such a construction. The rest of the grammar works with 

7, older versions of Sicstus (0.7) as well. 

spr_head rule 

(Mother, @sat) ===> 
cat> 

(Spr, ©sat) , 
cat> 

(Head, @val_spr ( [Spr] ) , @subj_sat, @comps_sat, 
@no_to_slash) , 

goal> 

(spec_p(Head,Spr) , 

dtrs (Mother , @spr_head_cs (Spr , Head) ) , 
principles (Mother, Head, Head, [Head, Spr] ,Head)) . 

y t =================================================== 

°/ c (5) adjunct head 

1=================================================== 

adjunct_head rule 

(Mother, phrase, @val(Val)) ===> 
cat> 

(Adjunct, Omod(Synsem) ) , 
cat> 

(Head, (synsem: Synsem) , Oval(Val), 
@no_to_slash) , 

goal> 

(dtrs (Mother , @adjunct_head_cs (Adjunct , Head) ) , 
principles (Mother, Head, Adjunct, [Head, Adjunct] .Head)) . 

1=================================================== 

'/, (6) filler head 

1=================================================== 

filler_head rule 

(Mother, phrase, @sat) ===> 
cat> 
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(Filler, @in_slash(Filler_in_slash_list) ) , 
cat> 

(Head, ©verb, @fin, @sat, @plus_inv, 
@in_slash( [Filler] ) , 

@to_slash( [Filler I Filler_in_slash_list] ) ) , 

goal> 

(dtrs(Mother, @f iller_head_cs(Filler,Head)) , 
principles (Mother, Head, Head, [Head, Filler] ,Head)) . 

% ********************************************^ 
Definite Clauses 

7, ################# 

% I. Non-Linguistic 
% ################# 

7. 

% lists of quant 
7. 

append_quant ( [] , L , L) if true . 
append_quant([H|Tl] ,L, [H|T2]) if 
append, quant (T1,L,T2) . 

% insert_quant(+element, +list, - (list&element) 
7. 

insert_quant(X,L,R) if list_del_quant(X,R,L) . 
% list_del_quant(quant,quant_list,quant_list - quant) 

7. 

list_del_quant(X, [X|R], R) if true. 
list_del_quant(X, [Y|R1], [Y|R2]) if 
list_del_quant(X,Rl,R2) . 

7. 

7 lists of quant and set of quant 
7. 

7o set_sublist_rest_quant (Setl ,List , Set 2) 

% Extracts elements out of Setl and add them in any order to List, the 
% rest is stored in Set2. 

set_sublist_rest_quant(eset, [] ,eset) if true. 
set_sublist_rest_quant(@set(H,T) , L.Oset (H,R) ) if 

set_sublist_rest_quant(T,L,R) . 
set_sublist_rest_quant (@set (H , T) , L,R) if 

set_sublist_rest_quant(T,Ll,R) , 

insert_quant(H,Ll,L) . 

7. 

7. lists of signs 

7. 

max_l_list( [] , _) if true. 
max_l_list( [_] , plus) if true. 

append ([] ,L,L) if true, 
append ([H | Tl] ,L, [H|T2]) if 
append(Tl,L,T2) . 
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7 list_del (element, list, list - element) 
7. 

list.delCX, [XIR], R) if true, 
list.deltt, [YIR1], [YIR2]) if 
list_del(X,Rl,R2) . 

7 power_list(listl, powerlist_element of list 1, elements not in powerlist_element) 
7. 

power_list (L, L, [] ) if true. 
power_list(L,M,[F|R]) if 

list_del(F,L,0) , 

power_list(a,M,R) . 

'/, list_diff C+listl,+list2,-(listl - elements of list2)) (-> token-identity-check) 
7. 

list_diff(X, [] , X) if true, 
list.diff (L, [E I F] , R) if 

list_del(E, L, LI), 

list_diff (LI, F, R) . 

'/, switch_list .element (element _old, element_new, list_old, list _new) 

7. 

switch_list_element (E,E1 , [E|R] , [El |R] ) if true. 
switch_list_element(E,El, [F|R] , [F|R1]) if 
switch_list_element(E,El,R,Rl) . 

7. 

7. sets 
7. 

'/, union_quant(setl_quant,set2_quant,result_quant) = set version of append_quant 
% 

union_quant(eset,X,X) if true. 
union_quant (@set (X , R) , Y , @set (X , Z) ) if 
union_ quant (R,Y,Z) . 

V, 

'/, specific sets 

7. 

7. union_qstore(+list(dtrs) , -union (qstore_of _dtrs) ) 
7. 

union_qstore( [] , eset) if true. 
union_qstore( [(qstore: Q) I R] , S) if 

union_qstore(R,Sl) , 

union_ quant (Q, SI, S) . 

collect_in_slash(+list(dtrs) , -list (inherited slashes)) 

% 

collect_in_slash( [] , [] ) if true. 
collect_in_slash( [@in_slash(In) I R] , In2) if 

collect_in_slash(R,Inl) , 

append(In,Inl,In2) . 

'/, ################# 

*/, II. Non Linguistic on theory-specific data types 
% ################# 

7c building parse tree (separated here from real linguistics) : 
% 

dtrs ( (dtrs : Const_struc) , Const_struc) if true . 
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V. ############## 

% III. Linguistic 
'/. ############## 



I =========================================== 

7, A. Principles applied to all constructions 
• /o =========================================== 

principles (Mother , Head, Sem_head, Dtr_list, Marking^dtr) if 
(hfp (Mother, Head), 
nfp(Mother, Head, Dtr_list) , 
sem_p(Mother, Sem_head, Dtr_list) , 
marking_p (Mother, Marking_dtr) ) . 

% 

% Head-Feature Principle 
% 

hfp(@head(X) ,@head(X)) if true . 

% 

% Nonlocal Principle 

% 

nfp(@in_slash(Diff ) , ©to_slash(Head_To_slash) , Dtr_list) if 
(collect_in_slash(Dtr_list , In_slash) , 
list_diff (In_slash,Head_To_slash,Diff )) . 

% 

7, Semantics Principle 
• /o 

sem_p( (@cont(Cont) , qstore : Qstore , retr:Retr), 
Ocont (Cont_Hd) , 
Dtrs) if 

union_qstore (Dtrs , Qstore_Dtrs) , 

sem_p_choice(Cont, Qstore, Retr, Cont_Hd, Qstore_Dtrs) . 

sem_p_choice( (psoa, (quants : Q , nucl:N)), Qstore, Retr, 

(psoa, (quants:Q_Hd, nucl:N)), Qstore_Dtrs) if 
set_sublist_rest_quant (Qstore^Dtrs , Retr , Qstore) , 

append_quant((Retr,e_list) ,Q_Hd,Q) . % no quantifiers retrieved (cf . uDRS) 
sem_p_choice ( (Cont , (nom_obj ; quant) ) , Qstore , [] , Cont , Qstore) if true . 

% 

% Marking Principle 

x 

marking_p(@marking(X) , QmarkingCX)) if true. 

I =========================================== 

7o B. Principles applied to some constructions 

x =========================================== 

I 

% Specifier Principle 

X 

% applied to: 

% head-marker and head-specifier constructions 
7» ( = constructions with a functional daughter, 
% i.e. whose head value is "func") 
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spec_p( (synsem: Head_synsem) , 

(synsem: loc : cat : head: spec : Head_synsem) ) if true . 



*/, System stuff for use in the grammar 

'/ e + *+*+***************************************^ 

7 Predicates used for lexicon access: 

transf orm( [],[]). 

transf orm( [A I Rl] , [B I R2] ) : - 

name(B, [A]), 

transf orm(Rl,R2) . 

7 explode(+,-) : converts atoms to lists of characters; very 

'/, inefficient and works only in one direction 

'/, 

explode ( In , Out) : - 
name(In,Ll) , 
transform(Ll,Qut) . 

7 Test sentences 
7 

7 A note on the number of solutions 

7. 

7 Most test sentences only have one admissible structure. If more than 
7 one solution is found, the implementation is incorrect. This is not 
7 true for certain cases: 
'/, 

'/ ( 1. NPs can have several parses because of one morphology fitting 
7 several case and number specifications . 

7 

7 2. Finite sentences with intransitive verbs can be inverted or 

7 non-inverted. The following pairs are therefore indistinguishable: 

7 a) finite verb in last position = finite verb in second position 

7 b) finite verb flipped before vc = finite verb in second position 

7 

'/, 3. In verbal complexes in which the highest auxiliary has bse 

7 morphology, that auxiliary is ambiguous between bse and subst-bse . 

7 

7 Note: The examples marked with a * have no correct parses. 

7 

7 

I =============================================== 

7 I. General Constructions 

y t =============================================== 

% NPs 

t (1 , [der.kleine ,mann] ) . 

t(2, [ein.guter.tisch] ) . 

t(3, [einige,kleine,verwandte] ) . 

t(4, [kein,guter,kleiner,tisch] ) . 
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7 Verbal projections 



77.77,77,77,77, 

7 1 verb 

77.77,77,77,77, 

7 A. VPs 

7 bse 

t (5, [das.gute ,buch,f inden] ) . 

t (6, [dem, verwandten,das ,gute,buch,geben] ) . 

7 psp 

t (7 , [das , gute ,buch, gef unden] ) . 

t(8, [dem, verwandten, das, gute, buch ,gegeben] ) . 

7 B. Sentences 

7 non-inverted 
t (9 , [der , kleine ,mann, lacht] ) . 
t (10 , [der , kleine ,mann, das ,gute ,buch, f indet] ) . 
t (11, [der , kleine, mann, dem, verwandten, das , gute , buch, gibt] ) . 

7 non-inverted & complementizer 
t (12, [dass, der, kleine , mann, lacht] ) . 
t (13, [dass, der, kleine , mann, das , gute , buch, f indet] ) . 
t (14, [dass, der, kleine , mann, dem, verwandten, das , gute , buch, gibt] ) . 

7 inverted 
t (15, [lacht , der , kleine, mann] ) . 
t (16, [f indet , der, kleine , mann, das , gute , buch] ) . 
t (17, [gibt , der, kleine , mann, dem, verwandten, das , gute , buch] ) . 

7 inverted + subj topicalized: 
t(18, [der, kleine, mann, lacht] ) . 
t (19, [der , kleine, mann, f indet , das , gute , buch] ) . 
t (20, [der .kleine, mann, gibt , dem, verwandten, das , gute , buch] ) . 

7 inverted + acc-obj topicalized: 
t (21 , [das , gute, buch, f indet , der , kleine , mann] ) . 
t (22, [das , gute, buch, gibt , der, kleine , mann, dem, verwandten] ) . 

7 inverted + dat-obj topicalized: 
t (23, [dem, verwandten, gibt , der .kleine, mann, das , gute , buch] ) . 



77,77,77,77,77, 
7 2 verbs 
77,77,77,77,77, 

7 A. VPs 
7 bse 

t (24, [das , gute, buch, f inden, wollen] ) . 

t (25, [dem, verwandten, das, gute , buch, geben, wollen] ) . 

7 psp 

t (26 , [das , gut e , buch, gef unden, haben] ) . 

t (27, [dem, verwandten, das, gute , buch, gegeben, haben] ) . 
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B. Sentences 



°/ non-inverted 
t (28, [der ,kleine,mann,lachen, wird] ) . 
t(29, [der, kleine.mann, das, gute ,buch, f inden, wird]) . 
t (30, [der , kleine.mann, dem , verwandt en, das , gute ,buch,geben, wird] ) . 

°/„ non-inverted & complementizer 
t (31 , [dass , der , kleine ,mann, lachen, wird] ) . 
t (32 , [dass , der , kleine ,mann, das ,gute ,buch, f inden, wird] ) . 
t (33, [dass, der, kleine ,mann, dem, verwandten, das , gute ,buch, geben, wird] ) . 

'/„ inverted 
t (34, [wird, der , kleine ,mann, lachen] ) . 
t (35, [wird, der, kleine ,mann, das , gute ,buch, f inden] ) . 
t (36, [wird, der, kleine ,mann, dem, verwandten, das , gute ,buch, geben] ) . 

°/ inverted + subj topicalized: 
t(37, [der, kleine.mann, wird, lachen] ) . 
t (38, [der , kleine.mann, wird, das , gute ,buch,f inden] ) . 
t (39, [der , kleine.mann, wird, dem, verwandten, das , gute ,buch, geben] ) . 

% inverted + acc-obj topicalized: 
t (40 , [das , gut e ,buch, wird, der , kleine ,mann, f inden] ) . 
t (41 , [das , gute, buch, wird, der, kleine ,mann,dem, verwandten, geben] ) . 

% inverted + dat-obj topicalized: 
t (42, [dem, verwandten, wird, der , kleine.mann, das , gute , buch, geben] ) . 

yx/xavxa 

7 3 verbs 

yx/x/x/xa 

l A. VPs 
% bse 

t (43, [das , gute, buch, f inden, wollen, werden] ) . 

t (44 , [dem , verwandten , das , gute , buch , geben , wollen , werden] ) . 

% psp 

t (45 , [das , gute , buch , gef unden , haben , werden] ) . 

t (46 , [dem , verwandten , das , gute , buch , gegeben , haben , werden] ) . 

°/„ B. Sentences 

°/„ non-inverted 
t(47, [der, kleine.mann, lachen, wollen, wird] ) . 
t (48, [der , kleine.mann, das , gute , buch, f inden, wollen, wird] ) . 
t (49, [der , kleine.mann, dem, verwandt en, das , gute , buch, geben, wollen, wird] ) . 

% non-inverted & complementizer 
t (50, [dass, der, kleine ,mann, lachen, wollen, wird] ) . 
t(51, [dass, der, kleine.mann, das, gute, buch, f inden, wollen, wird] ) . 
t (52, [dass, der, kleine ,mann, dem, verwandten, das , gute , buch, geben, wollen, wird] ) . 

'/„ inverted 

t (53 , [wird, der , kleine ,mann, lachen, wollen] ) . 

t (54, [wird, der, kleine ,mann, das , gute , buch, f inden, wollen] ) . 

t (55, [wird, der, kleine ,mann, dem, verwandten, das , gute , buch, geben, wollen] ) . 



xli 



°/„ inverted + subj topicalized: 
t(56, [der, kleine.mann, wird, lachen, wollen] ) . 
t (57 , [der , kleine ,mann, wird, das ,gute , buch, f inden, wollen] ) . 
t (58, [der , kleine.mann, wird, dem, verwandten, das , gute , buch, geben, wollen] ) . 

°/ inverted + acc-obj topicalized: 
t (59 , [das , gut e , buch, wird, der , kleine ,mann, f inden, wollen] ) . 
t (60, [das , gute, buch, wird, der, kleine ,mann,dem, verwandten, geben, wollen] ) . 

°/„ inverted + dat-obj topicalized: 
t (61 , [dem, verwandten, wird, der , kleine.mann, das , gute , buch, geben, wollen] ) . 

%%%%%%%%%% 

°/ 4 verbs 

vxaxavx/. 

l A. Vps 
bse 

t (62, [das , gute, buch, f inden, koennen, wollen, werden] ) . 

t (63, [dem, verwandten, das, gute , buch, geben, koennen, wollen, werden] ) . 

'/„ psp -> flipped 
t (64, [das , gute, buch, werden, haben, f inden, koennen] ) . 
t (65, [dem, verwandten, das, gute , buch, werden, haben, geben, koennen] ) . 

% B. Sentences 

% non-inverted 
t(66, [der, kleine.mann, lachen, koennen, wollen, wird] ) . 
t (67 , [der , kleine ,mann, das ,gute , buch, f inden, koennen, wollen, wird] ) . 
t (68, [der , kleine.mann, dem, verwandten, das , gute , buch, geben, koennen, wollen, wird] ) . 

°/„ non-inverted & complementizer 
t (69, [dass, der, kleine ,mann, lachen , koennen, wollen, wird] ) . 
t (70, [dass, der, kleine ,mann, das , gute , buch, f inden, koennen, wollen, wird] ) . 
t (71, [dass, der, kleine ,mann, dem, verwandten, das , gute , buch, geben, koennen , wollen, wird] ) . 

°/„ inverted 

t (72 , [wird, der , kleine ,mann, lachen .koennen, wollen] ) . 

t (73 , [wird, der , kleine ,mann, das ,gute , buch, f inden, koennen, wollen] ) . 

t (74, [wird, der .kleine ,mann, dem, verwandten, das , gute , buch, geben, koennen .wollen] ) . 

% inverted + subj topicalized: 
t(75, [der, kleine.mann, wird, lachen, koennen, wollen] ) . 
t (76 , [der .kleine ,mann, wird, das ,gute , buch, f inden, koennen, wollen] ) . 
t (77, [der , kleine.mann, wird, dem, verwandten, das , gute , buch, geben, koennen, wollen] ) . 

% inverted + acc-obj topicalized: 
t (78 , [das , gute , buch , wird , der , kleine ,mann , f inden , koennen , wollen] ) . 
t (79, [das , gute, buch, wird, der, kleine ,mann, dem, verwandten, geben, koennen, wollen] ) . 

°/„ inverted + dat-obj topicalized: 
t (80, [dem, verwandten, wird, der , kleine.mann, das , gute , buch, geben, koennen, wollen] ) . 
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X =========================== 

'/, II. Special Constructions 

X =========================== 



X 

7. P(VP) Topicalization 

x 

•1:1:1:1:1:1:1:1:1:1. 

'/, 1 verb 
•i:i:i:i:i:i:i:i:i:i, 

"I, main v 

t (81 , [lachen, wird.der , kleine , mann] ) . 

t(82, [finden,wird,der, kleine, maim, das, gute,buch]) . 

t (83, [geben, wird.der, kleine ,mann,dem, verwandten, das ,gute ,buch] ) . 

% main v + obj 
t (84, [das ,gute,buch, finden,wird,der, kleine, mann] ) . 
t (85, [das ,gute, buch, geben, wird,der , kleine, mann, dem, verwandten] ) . 
t (86, [dem, verwandten, geben, wird.der, kleine , mann, das ,gute , buch] ) . 

°/„ main v + objl + obj 2 
t (87 , [dem, verwandten, das , gute , buch, geben, wird,der , kleine ,mann] ) . 

vx/x/x/xa 

°/ 2 verbs 

vx/x/x/xa 

a) aux stays in back 
'/„ main v 

t (88 , [lachen, wird, der , kleine , mann, koennen] ) . 

t (89, [finden,wird,der, kleine, mann, das , gute , buch, koennen] ) . 

t (90, [geben, wird.der, kleine , mann, dem, verwandten, das , gute , buch, koennen] ) . 

°/ main v + obj 

t (91 , [das , gute, buch, f inden, wird,der , kleine, mann, koennen] ) . 

t (92, [das , gute, buch, geben, wird,der, kleine, mann, dem, verwandten, koennen] ) . 

t (93, [dem, verwandten, geben, wird.der .kleine , mann, das , gute , buch, koennen] ) . 

°/„ main v + objl + obj 2 
t (94, [dem, verwandten, das , gute , buch, geben, wird.der , kleine , mann, koennen] ) . 

b) aux topicalized as well 

°/„ main v + aux 
t(95, [lachen, koennen, wird.der, kleine, mann] ) . 
t (96, [f inden, koennen, wird.der .kleine, mann, das , gute , buch] ) . 
t (97, [geben, koennen, wird.der, kleine , mann, dem, verwandten, das, gute, buch] ) . 

°/ main v + aux + obj 
t (98, [das , gute, buch, f inden, koennen, wird.der , kleine , mann] ) . 
t (99 , [das , gut e , buch, geben, koennen, wird ,der , kleine , mann, dem, verwandten] ) . 
t (100 , [dem, verwandten, geben, koennen, wird, der, kleine , mann , das , gute ,buch] ) . 

main v + aux + objl + obj 2 
t (101 , [dem, verwandten, das , gute , buch, geben, koennen, wird, der , kleine , mann] ) . 
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vx/x/x/xa 

°/„ 3 verbs 

vx/x/x/xa 



a) both auxs stay in back 
main v 

t (102 , [lachen, wird, der , kleine , mann, koennen, wollen] ) . 

t (103 , [f inden, wird, der , kleine , mann, das ,gute , buch, koennen , wollen] ) . 

t(104, [geben, wird, der, kleine, mann, dem, verwandten, das, gute, buch, koennen, wollen] ) . 

°/ main v + obj 

t (105 , [das , gute , buch, f inden, wird, der , kleine , mann, koennen , wollen] ) . 

t (106 , [das , gute , buch, geben, wird, der , kleine , mann, dem , verwandten, koennen, wollen] ) . 

t (107 , [dem, verwandten, geben, wird, der , kleine , mann, das , gute , buch, koennen, wollen] ) . 

°/„ main v + objl + obj 2 
t ( 108 , [dem , verwandten , das , gute , buch , geben , wird , der , kleine , mann , koennen , wollen] ) . 

b) one aux topicalized as well 

°/„ main v + aux 
t (109 , [lachen, koennen, wird, der , kleine , mann, wollen] ) . 
t (110 , [f inden, koennen, wird, der , kleine , mann, das , gute , buch , wollen] ) . 
t (111 , [geben, koennen, wird, der , kleine , mann, dem, verwandten , das , gute , buch, wollen] ) . 

°/ main v + aux + obj 
t (112 , [das , gute , buch, f inden, koennen, wird.der , kleine , mann , wollen] ) . 
t (113 , [das , gute , buch, geben, koennen, wird, der , kleine , mann, dem, verwandten, wollen] ) . 
t (114 , [dem, verwandten, geben, koennen, wird, der , kleine , mann , das , gute , buch, wollen] ) . 

main v + aux + objl + obj 2 
t ( 1 15 , [dem , verwandten , das , gute , buch , geben , koennen , wird , der , kleine , mann , wollen] ) . 

c) both auxs topicalized 

°/„ main v + aux + aux 
t(116, [lachen, koennen, wollen, wird, der, kleine, mann] ) . 
t (117, [f inden, koennen, wollen, wird, der , kleine, mann, das , gute , buch] ) . 
t ( 1 18 , [geben , koennen , wollen , wird , der , kleine ,mann , dem , verwandten , das , gute , buch] ) . 

°/„ main v + aux + aux + obj 
t (119 , [das , gute , buch, f inden, koennen, wollen, wird, der , kleine ,mann] ) . 
t (120 , [das , gute , buch, geben, koennen, wollen, wird, der , kleine , mann, dem, verwandten] ) . 
t ( 121 , [dem , verwandten , geben , koennen , wollen , wird , der , kleine ,mann , das , gute , buch] ) . 

main v + aux + aux + objl + obj 2 
t ( 122 , [dem , verwandten , das , gute , buch , geben , koennen , wollen , wird , der , kleine , mann] ) . 

% 

7o AUX Flip 

% 

vx/x/x/xa 

°/„ 3 verbs 

vx/x/x/xa. 

Optional 

t (123, [dass , der , kleine, mann, wird, lachen, wollen] ) . 

t (124 , [dass , der , kleine , mann, das , gute , buch, wird, f inden, wollen] ) . 

t (125, [dass , der , kleine, mann, dem, verwandten, das, gute , buch, wird, geben, wollen] ) . 
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°/c Obligatory (substitute infinitive) 
t (126 , [dass , der , kleine , mann, hat , lachen , wollen] ) . 
t ( 127 , [dass , der , kleine , mann , das , gute , buch , hat , f inden , wollen] ) . 
t (128, [dass , der , kleine, mann, dem, verwandten, das, gute , buch, hat ,geben, wollen] ) . 

%%%%%%%%%% 
% 4 verbs 
%%%%%%%%%% 

% Optional 

t (129, [dass , der , kleine, mann, wird, lachen, koennen, wollen] ) . 

t (130, [dass , der , kleine, mann, das, gute, buch, wird, f inden, koennen, wollen] ) . 

t ( 131 , [dass , der , kleine , mann , dem , verwandten , das , gute , buch , wird , geben , koennen , wollen] ) . 

t (132 , [dass , der , kleine , mann, wird, wollen, lachen, koennen] ) . 

t (133 , [dass , der , kleine , mann, das , gute , buch, wird, wollen, f inden, koennen] ) . 

t (134 , [dass , der , kleine , mann, dem, verwandten, das , gute , buch , wird, wollen, geben .koennen] ) . 

% Obligatory (substitute infinitive) 
t (135, [dass , der , kleine, mann, wird, haben, lachen, koennen] ) . 
t (136, [dass , der , kleine, mann, das, gute, buch, wird, haben, f inden, koennen] ) . 
t (137, [dass , der , kleine, mann, dem, verwandten, das, gute , buch, wird, haben, geben, koennen] ) . 

% =============================================== 

% III. Some interesting linguistic examples 

% =============================================== 

°/„ Note: ungrammatical examples are marked with a * 

% 

7, AUX Flip 

% 

7. 

% 1. obligatory 

7. 

7. a) VL 

% double aux flip (wollen = substitute infinitive) 
t ( 138 , [dass , karl , das , buch , wird , haben , lesen , wollen] ) . 

7 wird not flipped: ungrammatical 
t (139, [dass , karl, das, buch, wird, lesen, wollen, haben] ) . % * 
t (140, [dass , karl, das, buch, wird, lesen, gewollt, haben] ) . °/ * 

°/„ both auxs not flipped: 
t (141 , [dass ,karl , das , buch, lesen, wollen , haben, wird] ) . '/„ * 
t (142, [dass , karl, das, buch, lesen, gewollt , haben, wird] ) . 

7. b) V2 

'/„ double aux flip (wollen = substitute infinitive) 
t (143, [karl, wird, das , buch, haben, lesen, wollen] ) . 

t(144, [karl, wird, das, buch, lesen, wollen, haben] ) . °/ * 
t(145, [karl, wird, das, buch, lesen, gewollt, haben] ) . 
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7. 

7o 2. optional 
7. 

7. a) VL 

"L flipped: 

t (146, [dass , der , mann, anna, wird, f inden, muessen] ) . 

°/„ not flipped: 
t (147, [dass ,der , mann, anna, f inden, muessen, wird] ) . 

7 no V2, since only werden and haben are assumed to be able to flip 

% 

7o Topicalization 

% 

7. 

7. 1. NPs 

7. 

X Norn NP 

t (148, [der, kleine ,verwandte , hat .gelacht] ) . 
% Akk NP 

t (149, [das, buch, hat , karl, lesen, wollen] ) . 
7, Dat NP 

t (150, [dem, mann, hat ,sarah, die .geschichte ,erzaehlen, muessen] ) . 

7. 

°/ 2. possibly partial VPs 

7. 

7«main v 
t (151 , [lachen, wird, anna] ) . 

7« partial vp 
t (152, [ein, kleines, buch, geben, wird, sarah, karl] ) . 
t (153, [den, verwandten, erzaehlen, muss, anna, die .geschichte] ) . 

7. full vp 

t (154, [dem, kleinen, mann, das , gute , buch, geben, wird, karl] ) . 

% 

7 Some fancy stuff 

% 

t(155, [karl, geben, muessen, wird, anna, das, buch, haben, wollen]) . 

t(156, [einigen, kleinen, maennern, erzaehlt , haben, muessen, wird, der, verwandte , die, gute, geschichte, woll 
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Appendix B: A test run 



For this test run, ALE 1.0 (release 1 May 1993) under SICStus 2.1 #9 was used on a Sun SPARC 10 with two 
40MHz Super Sparc CPUs and 48Mb Ram. 

I ?- test.all. 

* 1 » der 1 kleine 2 maim 3 

D.k. ** CPU time used (sec): 0.2, Solutions: 1 
************************************************************** 

* 2 » ein 1 guter 2 tisch 3 

D.k. ** CPU time used (sec): 0.1, Solutions: 1 
******************************************************************* 

* 3 » einige 1 kleine 2 verwandte 3 

O.k. ** CPU time used (sec): 0.7, Solutions: 4 
******************************************************************* 

* 4 >> kein 1 guter 2 kleiner 3 tisch 4 

O.k. ** CPU time used (sec): 0.2, Solutions: 1 
******************************************************************* 

* 5 >> das 1 gute 2 buch 3 finden 4 

O.k. ** CPU time used (sec): 0.5, Solutions: 1 
******************************************************************* 

* 6 >> dem 1 verwandten 2 das 3 gute 4 buch 5 geben 6 
O.k. ** CPU time used (sec): 1.0, Solutions: 1 
******************************************************************* 

* 7 >> das 1 gute 2 buch 3 gefunden 4 

O.k. ** CPU time used (sec): 0.4, Solutions: 1 
******************************************************************* 

* 8 » dem 1 verwandten 2 das 3 gute 4 buch 5 gegeben 6 
O.k. ** CPU time used (sec): 0.9, Solutions: 1 
******************************************************************* 

* 9 >> der 1 kleine 2 mann 3 lacht 4 

O.k. ** CPU time used (sec): 0.3, Solutions: 2 
*************************************************************** 

* 10 » der 1 kleine 2 mann 3 das 4 gute 5 buch 6 findet 7 
O.k. ** CPU time used (sec): 0.9, Solutions: 1 

* 11 » der 1 kleine 2 mann 3 dem 4 verwandten 5 das 6 gute 7 buch 8 gibt 9 
O.k. ** CPU time used (sec): 1.4, Solutions: 1 
******************************************************************* 

* 12 » dass 1 der 2 kleine 3 mann 4 lacht 5 
O.k. ** CPU time used (sec): 0.4, Solutions: 1 
******************************************************************* 

* 13 » dass 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 findet 8 
O.k. ** CPU time used (sec): 1.0, Solutions: 1 
******************************************************************* 

* 14 » dass 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 gibt 10 
O.k. ** CPU time used (sec): 1.5, Solutions: 1 
******************************************************************* 

* 15 » lacht 1 der 2 kleine 3 mann 4 

O.k. ** CPU time used (sec): 0.3, Solutions: 1 
******************************************************************* 

* 16 » findet 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 
O.k. ** CPU time used (sec): 0.8, Solutions: 1 

* 17 » gibt 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 
O.k. ** CPU time used (sec): 1.3, Solutions: 1 
******************************************************************* 

* 18 » der 1 kleine 2 mann 3 lacht 4 

O.k. ** CPU time used (sec): 0.3, Solutions: 2 
******************************************************************* 

* 19 » der 1 kleine 2 mann 3 findet 4 das 5 gute 6 buch 7 
O.k. ** CPU time used (sec): 1.0, Solutions: 1 
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******************************************************************* 

* 20 » der 1 kleine 2 mann 3 gibt 4 dem 5 verwandten 6 das 7 gute 8 buch 9 
O.k. ** CPU time used (sec): 1.4, Solutions: 1 
******************************************************************* 

* 21 » das 1 gute 2 buch 3 findet 4 der 5 kleine 6 mann 7 
O.k. ** CPU time used (sec): 0.9, Solutions: 1 

* 22 » das 1 gute 2 buch 3 gibt 4 der 5 kleine 6 mann 7 dem 8 verwandten 9 
O.k. ** CPU time used (sec): 1.5, Solutions: 1 

* 23 » dem 1 verwandten 2 gibt 3 der 4 kleine 5 mann 6 das 7 gute 8 buch 9 
O.k. ** CPU time used (sec): 1.4, Solutions: 1 
******************************************************************* 

* 24 » das 1 gute 2 buch 3 finden 4 wollen 5 
O.k. ** CPU time used (sec): 1.1, Solutions: 2 
******************************************************************* 

* 25 » dem 1 verwandten 2 das 3 gute 4 buch 5 geben 6 wollen 7 
O.k. ** CPU time used (sec): 2.3, Solutions: 2 
******************************************************************* 

* 26 » das 1 gute 2 buch 3 gefunden 4 haben 5 
O.k. ** CPU time used (sec): 0.9, Solutions: 2 
******************************************************************* 

* 27 » dem 1 verwandten 2 das 3 gute 4 buch 5 gegeben 6 haben 7 
O.k. ** CPU time used (sec): 2.0, Solutions: 2 
******************************************************************* 

* 28 » der 1 kleine 2 mann 3 lachen 4 wird 5 
O.k. ** CPU time used (sec): 0.5, Solutions: 1 
******************************************************************* 

* 29 » der 1 kleine 2 mann 3 das 4 gute 5 buch 6 finden 7 wird 8 
O.k. ** CPU time used (sec): 1.3, Solutions: 1 
******************************************************************* 

* 30 » der 1 kleine 2 mann 3 dem 4 verwandten 5 das 6 gute 7 buch 8 geben 9 wird 10 
O.k. ** CPU time used (sec): 2.2, Solutions: 1 
******************************************************************* 

* 31 » dass 1 der 2 kleine 3 mann 4 lachen 5 wird 6 
O.k. ** CPU time used (sec): 0.5, Solutions: 1 
******************************************************************* 

* 32 » dass 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 finden 8 wird 9 
O.k. ** CPU time used (sec): 1.4, Solutions: 1 
******************************************************************* 

* 33 >> dass 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 geben 10 wird 11 
O.k. ** CPU time used (sec): 2.4, Solutions: 1 
******************************************************************* 

* 34 » wird 1 der 2 kleine 3 mann 4 lachen 5 
O.k. ** CPU time used (sec): 0.5, Solutions: 1 
******************************************************************* 

* 35 » wird 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 finden 8 
O.k. ** CPU time used (sec): 1.4, Solutions: 1 
******************************************************************* 

* 36 » wird 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 geben 10 
O.k. ** CPU time used (sec): 2.4, Solutions: 1 
******************************************************************* 

* 37 » der 1 kleine 2 mann 3 wird 4 lachen 5 
O.k. ** CPU time used (sec): 0.5, Solutions: 1 
******************************************************************* 

* 38 » der 1 kleine 2 mann 3 wird 4 das 5 gute 6 buch 7 finden 8 
O.k. ** CPU time used (sec): 1.4, Solutions: 1 
******************************************************************* 

* 39 » der 1 kleine 2 mann 3 wird 4 dem 5 verwandten 6 das 7 gute 8 buch 9 geben 10 
O.k. ** CPU time used (sec): 2.1, Solutions: 1 
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******************************************************************* 

* 40 » das 1 gute 2 buch 3 wird 4 der 5 kleine 6 mann 7 finden 8 
O.k. ** CPU time used (sec): 1.3, Solutions: 1 
*************************************************************** 

* 41 » das 1 gute 2 buch 3 wird 4 der 5 kleine 6 mann 7 dem 8 verwandten 9 geben 10 
O.k. ** CPU time used (sec): 2.3, Solutions: 1 
******************************************************************* 

* 42 » dem 1 verwandten 2 wird 3 der 4 kleine 5 mann 6 das 7 gute 8 buch 9 geben 10 
O.k. ** CPU time used (sec): 2.3, Solutions: 1 
******************************************************************* 

* 43 » das 1 gute 2 buch 3 finden 4 wollen 5 werden 6 
O.k. ** CPU time used (sec): 2.2, Solutions: 2 
******************************************************************* 

* 44 » dem 1 verwandten 2 das 3 gute 4 buch 5 geben 6 wollen 7 werden 8 
O.k. ** CPU time used (sec): 4.4, Solutions: 2 
******************************************************************* 

* 45 » das 1 gute 2 buch 3 gefunden 4 haben 5 werden 6 
O.k. ** CPU time used (sec): 2.0, Solutions: 2 

* 46 >> dem 1 verwandten 2 das 3 gute 4 buch 5 gegeben 6 haben 7 werden 8 
O.k. ** CPU time used (sec): 4.1, Solutions: 2 
******************************************************************* 

* 47 » der 1 kleine 2 mann 3 lachen 4 wollen 5 wird 6 
O.k. ** CPU time used (sec): 0.8, Solutions: 1 
******************************************************************* 

* 48 » der 1 kleine 2 mann 3 das 4 gute 5 buch 6 finden 7 wollen 8 wird 9 
O.k. ** CPU time used (sec): 2.2, Solutions: 1 
******************************************************************* 

* 49 » der 1 kleine 2 mann 3 dem 4 verwandten 5 das 6 gute 7 buch 8 geben 9 wollen 10 wird 11 
O.k. ** CPU time used (sec): 3.9, Solutions: 1 
******************************************************************* 

* 50 » dass 1 der 2 kleine 3 mann 4 lachen 5 wollen 6 wird 7 
O.k. ** CPU time used (sec): 0.9, Solutions: 1 
******************************************************************* 

* 51 » dass 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 finden 8 wollen 9 wird 10 
O.k. ** CPU time used (sec): 2.3, Solutions: 1 
******************************************************************* 

* 52 » dass 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 geben 10 wollen 11 

wird 12 

O.k. ** CPU time used (sec): 4.1, Solutions: 1 
******************************************************************* 

* 53 » wird 1 der 2 kleine 3 mann 4 lachen 5 wollen 6 
O.k. ** CPU time used (sec): 0.9, Solutions: 1 
******************************************************************* 

* 54 » wird 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 finden 8 wollen 9 
O.k. ** CPU time used (sec): 2.4, Solutions: 1 

* 55 » wird 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 geben 10 wollen 11 
O.k. ** CPU time used (sec): 4.4, Solutions: 1 
******************************************************************* 

* 56 » der 1 kleine 2 mann 3 wird 4 lachen 5 wollen 6 
O.k. ** CPU time used (sec): 1.0, Solutions: 2 
******************************************************************* 

* 57 » der 1 kleine 2 mann 3 wird 4 das 5 gute 6 buch 7 finden 8 wollen 9 
O.k. ** CPU time used (sec): 2.6, Solutions: 1 
******************************************************************* 

* 58 » der 1 kleine 2 mann 3 wird 4 dem 5 verwandten 6 das 7 gute 8 buch 9 geben 10 wollen 11 
O.k. ** CPU time used (sec): 4.0, Solutions: 1 
******************************************************************* 

* 59 » das 1 gute 2 buch 3 wird 4 der 5 kleine 6 mann 7 finden 8 wollen 9 
O.k. ** CPU time used (sec): 2.1, Solutions: 1 
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******************************************************************* 

* 60 » das 1 gute 2 buch 3 wird 4 der 5 kleine 6 mann 7 dem 8 verwandten 9 geben 10 wollen 11 
O.k. ** CPU time used (sec): 4.1, Solutions: 1 
******************************************************************* 

* 61 » dem 1 verwandten 2 wird 3 der 4 kleine 5 mann 6 das 7 gute 8 buch 9 geben 10 wollen 11 
O.k. ** CPU time used (sec): 4.1, Solutions: 1 
******************************************************************* 

* 62 >> das 1 gute 2 buch 3 finden 4 koennen 5 wollen 6 werden 7 
O.k. ** CPU time used (sec): 4.4, Solutions: 2 
******************************************************************* 

* 63 » dem 1 verwandten 2 das 3 gute 4 buch 5 geben 6 koennen 7 wollen 8 werden 9 
O.k. ** CPU time used (sec): 8.0, Solutions: 2 
******************************************************************* 

* 64 » das 1 gute 2 buch 3 werden 4 haben 5 finden 6 koennen 7 
O.k. ** CPU time used (sec): 3.2, Solutions: 2 
******************************************************************* 

* 65 » dem 1 verwandten 2 das 3 gute 4 buch 5 werden 6 haben 7 geben 8 koennen 9 
O.k. ** CPU time used (sec): 6.3, Solutions: 2 

* 66 >> der 1 kleine 2 mann 3 lachen 4 koennen 5 wollen 6 wird 7 
O.k. ** CPU time used (sec): 1.6, Solutions: 1 
******************************************************************* 

* 67 » der 1 kleine 2 mann 3 das 4 gute 5 buch 6 finden 7 koennen 8 wollen 9 wird 10 
O.k. ** CPU time used (sec): 3.6, Solutions: 1 
******************************************************************* 

* 68 » der 1 kleine 2 mann 3 dem 4 verwandten 5 das 6 gute 7 buch 8 geben 9 koennen 10 wollen 

wird 12 

O.k. ** CPU time used (sec): 6.6, Solutions: 1 
******************************************************************* 

* 69 » dass 1 der 2 kleine 3 mann 4 lachen 5 koennen 6 wollen 7 wird 8 
O.k. ** CPU time used (sec): 1.8, Solutions: 1 
******************************************************************* 

* 70 » dass 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 finden 8 koennen 9 wollen 10 wird 11 
O.k. ** CPU time used (sec): 3.8, Solutions: 1 
******************************************************************* 

* 71 » dass 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 geben 10 koennen 11 

wollen 12 wird 13 
O.k. ** CPU time used (sec): 6.9, Solutions: 1 
******************************************************************* 

* 72 » wird 1 der 2 kleine 3 mann 4 lachen 5 koennen 6 wollen 7 
O.k. ** CPU time used (sec): 1.8, Solutions: 1 
******************************************************************* 

* 73 » wird 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 finden 8 koennen 9 wollen 10 
O.k. ** CPU time used (sec): 4.1, Solutions: 1 
******************************************************************* 

* 74 » wird 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 geben 10 koennen 11 

wollen 12 

O.k. ** CPU time used (sec): 7.4, Solutions: 1 
******************************************************************* 

* 75 » der 1 kleine 2 mann 3 wird 4 lachen 5 koennen 6 wollen 7 
O.k. ** CPU time used (sec): 2.1, Solutions: 2 
******************************************************************* 

* 76 » der 1 kleine 2 mann 3 wird 4 das 5 gute 6 buch 7 finden 8 koennen 9 wollen 10 
O.k. ** CPU time used (sec): 4.6, Solutions: 1 
******************************************************************* 

* 77 » der 1 kleine 2 mann 3 wird 4 dem 5 verwandten 6 das 7 gute 8 buch 9 geben 10 koennen 11 

wollen 12 

O.k. ** CPU time used (sec): 6.9, Solutions: 1 
******************************************************************* 

* 78 » das 1 gute 2 buch 3 wird 4 der 5 kleine 6 mann 7 finden 8 koennen 9 wollen 10 
O.k. ** CPU time used (sec): 3.6, Solutions: 1 
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******************************************************************* 

* 79 » das 1 gute 2 buch 3 wird 4 der 5 kleine 6 raann 7 dem 8 verwandten 9 geben 10 koennen 11 

wollen 12 

O.k. ** CPU time used (sec): 6.9, Solutions: 1 
*********************************************************** 

* 80 » dem 1 verwandten 2 wird 3 der 4 kleine 5 mann 6 das 7 gute 8 buch 9 geben 10 koennen 11 

wollen 12 

O.k. ** CPU time used (sec): 6.9, Solutions: 1 
******************************************************************* 

* 81 » lachen 1 wird 2 der 3 kleine 4 mann 5 
O.k. ** CPU time used (sec): 0.5, Solutions: 1 

* 82 » finden 1 wird 2 der 3 kleine 4 mann 5 das 6 gute 7 buch 8 
O.k. ** CPU time used (sec): 1.3, Solutions: 1 
*************************************************************** 

* 83 » geben 1 wird 2 der 3 kleine 4 mann 5 dem 6 verwandten 7 das 8 gute 9 buch 10 
O.k. ** CPU time used (sec): 2.0, Solutions: 1 
******************************************************************* 

* 84 » das 1 gute 2 buch 3 finden 4 wird 5 der 6 kleine 7 mann 8 
O.k. ** CPU time used (sec): 1.4, Solutions: 1 
******************************************************************* 

* 85 » das 1 gute 2 buch 3 geben 4 wird 5 der 6 kleine 7 mann 8 dem 9 verwandten 10 
O.k. ** CPU time used (sec): 2.2, Solutions: 1 
******************************************************************* 

* 86 » dem 1 verwandten 2 geben 3 wird 4 der 5 kleine 6 mann 7 das 8 gute 9 buch 10 
O.k. ** CPU time used (sec): 2.2, Solutions: 1 
******************************************************************* 

* 87 » dem 1 verwandten 2 das 3 gute 4 buch 5 geben 6 wird 7 der 8 kleine 9 mann 10 
O.k. ** CPU time used (sec): 2.2, Solutions: 1 
******************************************************************* 

* 88 » lachen 1 wird 2 der 3 kleine 4 mann 5 koennen 6 
O.k. ** CPU time used (sec): 0.9, Solutions: 1 
******************************************************************* 

* 89 >> finden 1 wird 2 der 3 kleine 4 mann 5 das 6 gute 7 buch 8 koennen 9 
O.k. ** CPU time used (sec): 2.1, Solutions: 1 
******************************************************************* 

* 90 » geben 1 wird 2 der 3 kleine 4 mann 5 dem 6 verwandten 7 das 8 gute 9 buch 10 koennen 11 
O.k. ** CPU time used (sec): 3.2, Solutions: 1 
******************************************************************* 

* 91 » das 1 gute 2 buch 3 finden 4 wird 5 der 6 kleine 7 mann 8 koennen 9 
O.k. ** CPU time used (sec): 1.9, Solutions: 1 
******************************************************************* 

* 92 » das 1 gute 2 buch 3 geben 4 wird 5 der 6 kleine 7 mann 8 dem 9 verwandten 10 koennen 11 
O.k. ** CPU time used (sec): 3.1, Solutions: 1 
******************************************************************* 

* 93 » dem 1 verwandten 2 geben 3 wird 4 der 5 kleine 6 mann 7 das 8 gute 9 buch 10 koennen 11 
O.k. ** CPU time used (sec): 3.1, Solutions: 1 
******************************************************************* 

* 94 » dem 1 verwandten 2 das 3 gute 4 buch 5 geben 6 wird 7 der 8 kleine 9 mann 10 koennen 11 
O.k. ** CPU time used (sec): 2.8, Solutions: 1 
******************************************************************* 

* 95 » lachen 1 koennen 2 wird 3 der 4 kleine 5 mann 6 
O.k. ** CPU time used (sec): 0.9, Solutions: 1 

* 96 » finden 1 koennen 2 wird 3 der 4 kleine 5 mann 6 das 7 gute 8 buch 9 
O.k. ** CPU time used (sec): 1.9, Solutions: 1 
******************************************************************* 

* 97 » geben 1 koennen 2 wird 3 der 4 kleine 5 mann 6 dem 7 verwandten 8 das 9 gute 10 buch 11 
O.k. ** CPU time used (sec): 3.1, Solutions: 1 
******************************************************************* 

* 98 » das 1 gute 2 buch 3 finden 4 koennen 5 wird 6 der 7 kleine 8 mann 9 
O.k. ** CPU time used (sec): 2.2, Solutions: 1 
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******************************************************************* 

* 99 » das 1 gute 2 buch 3 geben 4 koennen 5 wird 6 der 7 kleine 8 mann 9 dem 10 verwandten 11 
O.k. ** CPU time used (sec): 3.5, Solutions: 1 
******************************************************************* 

* 100 » dem 1 verwandten 2 geben 3 koennen 4 wird 5 der 6 kleine 7 mann 8 das 9 gute 10 buch 1 
O.k. ** CPU time used (sec): 3.6, Solutions: 1 
******************************************************************* 

* 101 » dem 1 verwandten 2 das 3 gute 4 buch 5 geben 6 koennen 7 wird 8 der 9 kleine 10 mann 1 
O.k. ** CPU time used (sec): 3.8, Solutions: 1 
******************************************************************* 

* 102 » lachen 1 wird 2 der 3 kleine 4 mann 5 koennen 6 wollen 7 
O.k. ** CPU time used (sec): 1.9, Solutions: 2 
******************************************************************* 

* 103 » finden 1 wird 2 der 3 kleine 4 mann 5 das 6 gute 7 buch 8 koennen 9 wollen 10 
O.k. ** CPU time used (sec): 3.9, Solutions: 2 

* 104 » geben 1 wird 2 der 3 kleine 4 mann 5 dem 6 verwandten 7 das 8 gute 9 buch 10 koennen 1 

wollen 12 

O.k. ** CPU time used (sec): 6.0, Solutions: 2 
******************************************************************* 

* 105 » das 1 gute 2 buch 3 finden 4 wird 5 der 6 kleine 7 mann 8 koennen 9 wollen 10 
O.k. ** CPU time used (sec): 3.1, Solutions: 2 
******************************************************************* 

* 106 » das 1 gute 2 buch 3 geben 4 wird 5 der 6 kleine 7 mann 8 dem 9 verwandten 10 koennen 1 

wollen 12 

O.k. ** CPU time used (sec): 5.1, Solutions: 2 
******************************************************************* 

* 107 » dem 1 verwandten 2 geben 3 wird 4 der 5 kleine 6 mann 7 das 8 gute 9 buch 10 koennen 1 

wollen 12 

O.k. ** CPU time used (sec): 5.1, Solutions: 2 
******************************************************************* 

* 108 » dem 1 verwandten 2 das 3 gute 4 buch 5 geben 6 wird 7 der 8 kleine 9 mann 10 koennen 1 

wollen 12 

O.k. ** CPU time used (sec): 4.1, Solutions: 2 
******************************************************************* 

* 109 » lachen 1 koennen 2 wird 3 der 4 kleine 5 mann 6 wollen 7 
O.k. ** CPU time used (sec): 1.4, Solutions: 1 

* 110 » finden 1 koennen 2 wird 3 der 4 kleine 5 mann 6 das 7 gute 8 buch 9 wollen 10 
O.k. ** CPU time used (sec): 2.8, Solutions: 1 
******************************************************************* 

* 111 » geben 1 koennen 2 wird 3 der 4 kleine 5 mann 6 dem 7 verwandten 8 das 9 gute 10 buch 1 

wollen 12 

O.k. ** CPU time used (sec): 4.4, Solutions: 1 
******************************************************************* 

* 112 » das 1 gute 2 buch 3 finden 4 koennen 5 wird 6 der 7 kleine 8 mann 9 wollen 10 
O.k. ** CPU time used (sec): 2.8, Solutions: 1 
******************************************************************* 

* 113 » das 1 gute 2 buch 3 geben 4 koennen 5 wird 6 der 7 kleine 8 mann 9 dem 10 verwandten 1 

wollen 12 

O.k. ** CPU time used (sec): 4.5, Solutions: 1 
******************************************************************* 

* 114 » dem 1 verwandten 2 geben 3 koennen 4 wird 5 der 6 kleine 7 mann 8 das 9 gute 10 buch 1 

wollen 12 

O.k. ** CPU time used (sec): 4.6, Solutions: 1 
******************************************************************* 

* 115 » dem 1 verwandten 2 das 3 gute 4 buch 5 geben 6 koennen 7 wird 8 der 9 kleine 10 mann 1 

wollen 12 

O.k. ** CPU time used (sec): 4.4, Solutions: 1 
******************************************************************* 

* 116 » lachen 1 koennen 2 wollen 3 wird 4 der 5 kleine 6 mann 7 
O.k. ** CPU time used (sec): 1.7, Solutions: 1 
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******************************************************************* 

* 117 » finden 1 koennen 2 wollen 3 wird 4 der 5 kleine 6 maim 7 das 8 gute 9 buch 10 
O.k. ** CPU time used (sec): 3.1, Solutions: 1 
************************************************************** 

* 118 » geben 1 koennen 2 wollen 3 wird 4 der 5 kleine 6 mann 7 dem 8 verwandten 9 das 10 gute 11 

buch 12 

O.k. ** CPU time used (sec): 4.7, Solutions: 1 
*************************************************************** 

* 119 » das 1 gute 2 buch 3 finden 4 koennen 5 wollen 6 wird 7 der 8 kleine 9 mann 10 
O.k. ** CPU time used (sec): 3.6, Solutions: 1 
******************************************************************* 

* 120 » das 1 gute 2 buch 3 geben 4 koennen 5 wollen 6 wird 7 der 8 kleine 9 mann 10 dem 11 

verwandten 12 
O.k. ** CPU time used (sec): 5.6, Solutions: 1 
******************************************************************* 

* 121 » dem 1 verwandten 2 geben 3 koennen 4 wollen 5 wird 6 der 7 kleine 8 mann 9 das 10 gute 11 

buch 12 

O.k. ** CPU time used (sec): 5.7, Solutions: 1 
******************************************************************* 

* 122 » dem 1 verwandten 2 das 3 gute 4 buch 5 geben 6 koennen 7 wollen 8 wird 9 der 10 kleine 11 

mann 12 

O.k. ** CPU time used (sec): 6.2, Solutions: 1 
******************************************************************* 

* 123 » dass 1 der 2 kleine 3 mann 4 wird 5 lachen 6 wollen 7 
O.k. ** CPU time used (sec): 1.1, Solutions: 1 
******************************************************************* 

* 124 » dass 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 wird 8 finden 9 wollen 10 
O.k. ** CPU time used (sec): 2.1, Solutions: 1 
******************************************************************* 

* 125 » dass 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 wird 10 geben 11 

wollen 12 

O.k. ** CPU time used (sec): 3.3, Solutions: 1 
******************************************************************* 

* 126 >> dass 1 der 2 kleine 3 mann 4 hat 5 lachen 6 wollen 7 
O.k. ** CPU time used (sec): 1.0, Solutions: 1 
******************************************************************* 

* 127 » dass 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 hat 8 finden 9 wollen 10 
O.k. ** CPU time used (sec): 2.0, Solutions: 1 
******************************************************************* 

* 128 » dass 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 hat 10 geben 11 

wollen 12 

O.k. ** CPU time used (sec): 3.2, Solutions: 1 
******************************************************************* 

* 129 » dass 1 der 2 kleine 3 mann 4 wird 5 lachen 6 koennen 7 wollen 8 
O.k. ** CPU time used (sec): 2.3, Solutions: 1 
******************************************************************* 

* 130 » dass 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 wird 8 finden 9 koennen 10 wollen 11 
O.k. ** CPU time used (sec): 3.8, Solutions: 1 
******************************************************************* 

* 131 » dass 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 wird 10 geben 11 

koennen 12 wollen 13 
O.k. ** CPU time used (sec): 5.8, Solutions: 1 
******************************************************************* 

* 132 » dass 1 der 2 kleine 3 mann 4 wird 5 wollen 6 lachen 7 koennen 8 
O.k. ** CPU time used (sec): 1.8, Solutions: 1 
******************************************************************* 

* 133 » dass 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 wird 8 wollen 9 finden 10 koennen 11 
O.k. ** CPU time used (sec): 3.4, Solutions: 1 
******************************************************************* 

* 134 » dass 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 wird 10 wollen 11 

geben 12 koennen 13 
O.k. ** CPU time used (sec): 5.5, Solutions: 1 
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******************************************************************* 

* 135 » dass 1 der 2 kleine 3 mann 4 wird 5 haben 6 lachen 7 koennen 8 
O.k. ** CPU time used (sec): 1.8, Solutions: 1 
******************************************************************* 

* 136 » dass 1 der 2 kleine 3 mann 4 das 5 gute 6 buch 7 wird 8 haben 9 finden 10 koennen 11 
O.k. ** CPU time used (sec): 3.3, Solutions: 1 
******************************************************************* 

* 137 » dass 1 der 2 kleine 3 mann 4 dem 5 verwandten 6 das 7 gute 8 buch 9 wird 10 haben 11 

geben 12 koennen 13 
O.k. ** CPU time used (sec): 5.3, Solutions: 1 
******************************************************************* 

* 138 » dass 1 karl 2 das 3 buch 4 wird 5 haben 6 lesen 7 wollen 8 
O.k. ** CPU time used (sec): 2.4, Solutions: 1 

* 139 » dass 1 karl 2 das 3 buch 4 wird 5 lesen 6 wollen 7 haben 8 
### No parse!!!! ** CPU time used (sec): 1.8, Solutions: 

******************************************************************* 

* 140 » dass 1 karl 2 das 3 buch 4 wird 5 lesen 6 gewollt 7 haben 8 
### No parse!!!! ** CPU time used (sec): 1.3, Solutions: 

******************************************************************* 

* 141 » dass 1 karl 2 das 3 buch 4 lesen 5 wollen 6 haben 7 wird 8 
### No parse!!!! ** CPU time used (sec): 1.7, Solutions: 

******************************************************************* 

* 142 » dass 1 karl 2 das 3 buch 4 lesen 5 gewollt 6 haben 7 wird 8 
O.k. ** CPU time used (sec): 2.0, Solutions: 1 
******************************************************************* 

* 143 » karl 1 wird 2 das 3 buch 4 haben 5 lesen 6 wollen 7 
O.k. ** CPU time used (sec): 2.6, Solutions: 2 
******************************************************************* 

* 144 » karl 1 wird 2 das 3 buch 4 lesen 5 wollen 6 haben 7 
### No parse!!!! ** CPU time used (sec): 2.5, Solutions: 

******************************************************************* 

* 145 » karl 1 wird 2 das 3 buch 4 lesen 5 gewollt 6 haben 7 
O.k. ** CPU time used (sec): 2.4, Solutions: 2 
******************************************************************* 

* 146 >> dass 1 der 2 mann 3 anna 4 wird 5 finden 6 muessen 7 
O.k. ** CPU time used (sec): 1.3, Solutions: 1 

* 147 » dass 1 der 2 mann 3 anna 4 finden 5 muessen 6 wird 7 
O.k. ** CPU time used (sec): 1.4, Solutions: 1 
******************************************************************* 

* 148 » der 1 kleine 2 verwandte 3 hat 4 gelacht 5 
O.k. ** CPU time used (sec): 1.0, Solutions: 1 
******************************************************************* 

* 149 » das 1 buch 2 hat 3 karl 4 lesen 5 wollen 6 
O.k. ** CPU time used (sec): 1.5, Solutions: 2 
******************************************************************* 

* 150 » dem 1 mann 2 hat 3 sarah 4 die 5 geschichte 6 erzaehlen 7 muessen 8 
O.k. ** CPU time used (sec): 2.9, Solutions: 1 
******************************************************************* 

* 151 » lachen 1 wird 2 anna 3 

O.k. ** CPU time used (sec): 0.2, Solutions: 1 
******************************************************************* 

* 152 » ein 1 kleines 2 buch 3 geben 4 wird 5 sarah 6 karl 7 
O.k. ** CPU time used (sec): 1.4, Solutions: 1 
******************************************************************* 

* 153 » den 1 verwandten 2 erzaehlen 3 muss 4 anna 5 die 6 geschichte 7 
O.k. ** CPU time used (sec): 1.6, Solutions: 2 
******************************************************************* 

* 154 » dem 1 kleinen 2 mann 3 das 4 gute 5 buch 6 geben 7 wird 8 karl 9 
O.k. ** CPU time used (sec): 1.8, Solutions: 1 
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******************************************************************* 

* 155 » karl 1 geben 2 muessen 3 wird 4 anna 5 das 6 buch 7 haben 8 wollen 9 
O.k. ** CPU time used (sec): 7.4, Solutions: 2 
*************************************************************** 

* 156 » einigen 1 kleinen 2 maennern 3 erzaehlt 4 haben 5 muessen 6 wird 7 der 8 verwandte 9 

die 10 gute 11 geschichte 12 wollen 13 
O.k. ** CPU time used (sec): 6.4, Solutions: 1 
******************************************************************* 

Total CPU time: 6.86833 min — Average per sentence: 2.64167 sec 
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1 Introduction 

The paper documents the implementation of an HPSG theory for German in a constraint res- 
olution system. It illustrates the reasoning and the choices involved in the formalization and 
implementation of HPSG grammars. As basis for the reasoning, a discussion of the logical setup 
of the HPSG architecture as proposed in Pollard and Sag (1994) (henceforth HPSGII) is sup- 
plied. The relationship between a linguistic theory and its implementation is explored from a 
linguistic point of view. 

The grammar implemented covers the phenomena of aux-flip and partial verb phrase topical- 
ization in the three sentence types of German: verb first, verb second, and verb last. It closely 
follows the analyses proposed in Hinrichs and Nakazawa (1991) and Hinrichs and Nakazawa 
(1994) (henceforth HN), except for a few cases noted in section 5. 

The implementation is based on two systems: Bob Carpenter and Gerald Penn's ALE, and the 
Troll system developed by Dale Gerdemann and Thilo Gotz based on a logic by Paul King. The 
discussion of computational architectures in this paper also includes references to other systems, 
such as Martin Emele and Remi Zajac's TFS, or the CUF system developed by Jochen Dorre, 
Michael Dorna, and Andreas Eisele. 1 

The structure of the paper is as follows: The remaining part of this introduction briefly reports 
on the why and how of the project: the motivations behind the implementation, and the systems 
used. The second section describes the logical setup of HPSG: the description language and its 
interpretation. The third section deals with the feature logic building blocks of the HPSG ar- 
chitecture: the declaration of the domain of the grammar and the possibilities for formulating 
the constraints making up the linguistic theory. The focus is on the implications of the logical 
setup for the work of the linguist and examples from the implemented grammar are supplied. 
The fourth section goes through the linguistic modules of an HPSG theory: the lexicon, the 
specification of constituent structure, and the grammatical principles. The choices involved in 
formalizing them for implementation are discussed and illustrated with examples. The fifth 
section discusses the differences between the linguistic theory in HN and the implemented gram- 
mar and gives some technical comments on the implemented grammar. The complete grammar 
including a collection of test sentences and a test run are included in the appendix. 

1.1 Motivation 

There are at least two different motivations for implementing HPSG theories. 

From a computational point of view a complex theory serves well as a test for the feature 
logic systems being developed. It can illustrate performance and theoretic devices, such as 
named disjunction or full negation, or more specific mechanisms, like definite clause attachments 
on lexical entries. The line of thinking behind such implementations starts from the devices, 
explores their usefulness in compactly encoding linguistic generalizations, and then illustrates 
the computational setup in an implementation. Even though the intentions under this approach 
are oriented towards computation, the work can provide feedback for linguistics in supplying 
new theoretical devices for expressing linguistic theories. 

x For a brief overview of the main characteristics of TFS and CUF including some comments on the implications 
for the work of the linguist cf. Meurers and Gotz (1993). Manandhar (1993) is a comparison of ALE, CUF, and 
TFS regarding the expressive power of the type system, the definite clauses, and the control scheme. 



ON IMPLEMENTING AN HPSG THEORY 



3 



The intention of a linguist on the other hand is to use the development of an implementation as 
a tool to provide feedback for a rigid and complete formalization of a linguistic theory. Under 
this approach the work starts out from the theory and tries to put the mechanisms proposed in 
it to work together in a grammar in an elegant and correct fashion. 

Since the work presented here started out from a linguistic theory, it is closer to the second view. 
Nonetheless, the implementation also shows that both systems employed, ALE and Troll, can 
be used to express and process rather complex grammars. One of the effects of the linguistic 
approach pursued is that the implemented grammar tries to stay close to the notation and 
formulation used in the linguistic theory. The computational aspect causes some limitations 
here, the major one being the departure from ID/LP format due to the phrase structure based 
systems used. 

1.2 The systems used 

This section briefly introduces the computational setup of the implementation. A detailed 
discussion of the theoretical properties and differences between the two systems (which made it 
interesting to try to use the same grammar in both approaches) is included in the next sections, 
where the HPSG architecture and its logical foundation are discussed. 

The purpose of the Troll system is to efficiently implement a logic that gives a denotational 
semantics to typed feature structures as normal form descriptions as opposed to thinking of 
feature structures as models 2 . This allows unfilling of feature structures since there is a clear 
notion of semantic equivalence of different feature structures (cf. Gotz (1994)). Unfilling is an 
operation which removes arcs not constraining the denotation of a feature structure. Technically 
it allows for efficient representation of descriptions, while for the linguist it serves to suppress 
the information that can be inferred from the signature. Troll also assumes a closed world 
interpretation of type hierarchies which seems natural for linguistics and HPSG in particular. 

Due to the nature of Troll, the notation only represents the concepts relevant from the view- 
point of logic. For the implementation to reflect the linguistic theory, several extensions are 
necessary: Macros 3 serve to follow linguistic notation and avoid unnecessary, unclear and error 
prone repetition. Lexical rules, even though their theoretical status is not completely clear, are 
used in many HPSG publications including the one implemented, and therefore need to be part 
of the language. Finally, to enable debugging of a non-trivial grammar, a source level debugger 
allowing very selective output of information as well as good displaying and editing possibilities 
for the extensive feature structures is necessary. 

Since ALE 4 offers the first two devices, macros and something resembling lexical rules, the 
grammar was written in ALE, and then automatically translated 5 to Troll. At the time this 

2 This ontological difference between the logic of King (1989) and that of Carpenter (1992) is elaborated in 
section 2. 

3 The use of macros in the lexicon and the problems involved in replacing them with an appropriate formal 
mechanism are discussed in section 4.1.2. 

4 For a description of the ALE system, the reader is referred to Carpenter (1993). ALE Version 1.0, release: 1. 
May 1993 was used. All comments refer to that version. 

5 A technical note on the translation: Since in Troll everything is encoded in a feature structure data structure, 
a few special types (e.g. ps-rule) and a type for every definite clause together with its appropriate argument types 
are added to the translated grammar. Encoding definite clauses as feature structures enables the grammar writer 
to restrict the arguments of each definite clause type by specifying the signature. This enables the system to do 
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work was carried out, neither of the two systems offered a real debugger; so debugging of the 
grammar was done the old way: by thoroughly studying the grammar and massive testing. 

2 The HPSG ontology: A sketch of the logical foundations 

Before going through the ingredients of an HPSG grammar and the possibilities for formal- 
izing them in the various architectures, let us sketch the ontological and logical basis of the 
architectures we will mostly be dealing with: HPSG II, ALE, and Troll. 

This sketch seems worth making here, since the setup has direct consequences on the possibilities 
in and the extendibility of the logic based systems. A lot of the differences between the systems 
discussed later on can be traced back to the way the syntax and semantics of the logic behind the 
system is set up. Additionally this short introduction to the logical basis allows us to introduce 
the terminology needed later on (and its diverging use in the various architectures). 

The HPSG formalism as defined in HPSG II is at the basis of the linguistic analysis developed 
within the HPSG paradigm over the last several years. 6 We therefore start by looking at the 
ontological setup described in the introduction of HPSG II: 

In any mathematical theory about an empirical domain, the phenomena of interest 
are modelled by mathematical structures, certain aspects of which are conventionally 
understood as corresponding to observables of the domain. The theory itself does 
not talk directly about the empirical phenomena; instead, it talks about, or is inter- 
preted by, the modelling structures. Thus the predictive power of the theory arises 
from the conventional correspondence between the model and the empirical domain. 
(HPSG II, page 6) 

In other words, the first step of every scientific process is the modelling of the domain. Models 7 
of empirically observable objects are established to capture the relevant properties. Theories 
then make reference to these models. This opens up three questions: What do the mathematical 
structures used as models for HPSG theories look like? How are they related to the linguistic 
objects? and How is the linguistic theory put to work on the models? 

In HPSG, the modelling domain ... is a system of sorted feature structures, which 
are intended to stand in a one-to-one relation with types of natural language ex- 
pressions and their subparts. The role of the linguistic theory is to give a precise 
specification of which feature structures are to be considered admissible; the types 
of linguistic entities which correspond to the admissible feature structures constitute 
the predictions of the theory. (HPSG II, page 8) 

more static type checking. 

6 The setup of Pollard and Sag (1987) differs in several respects from that of HPSGII. 

7 Note that the term model has two usages: A mathematical entity which stands in a one-to-one relation to 
an object of the domain is called a model of that object. The second usage, which is avoided in this paper to 
prevent confusion, is to speak of the model of a theory as the set of "things" which are admitted by the theory. 
This double use of model is especially confusing, since the "things" in the formulation of the second usage, are 
often the models of objects in the first sense of the word. 
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The sorted feature structures chosen as models are graph theoretic entities. Pollard and Sag 
require them to be totally well-typed 8 and sort-resolved 9 . The reason for this is that feature 
structures that serve as models of linguistic entities are required to be total models of the 
objects that they represent. 10 To get the full picture of the setup proposed, we need to answer 
two more questions: 

How is a theory formulated? The theory is formulated using a specific description language. 11 
The description language allows us to express that a feature structure has to have a certain 
type, that the value of an attribute of a feature structure has to have a certain type, or that the 
values of two attributes of a feature structure are token identical 12 . Additionally conjunction, 
disjunction and full negation are defined as operators on the descriptions. 

What does it mean for a theory to specify admissible feature structures? A theory consists of 
a set of descriptions which are interpreted as being true or false of a feature structure in the 
domain. A feature structure is admissible with respect to a certain theory iff it satisfies each 
of the descriptions in the theory and so does each of its substructures. The descriptions which 
make up the theory are also called constraints, since these descriptions constrain the set of 
feature structures which are admissible with respect to the theory compared to the domain of 
feature structures specified by the signature. Note that the term constraint has been used for 
many different purposes. In this paper "constraint" will only be used for "description which is 
part of the theory". 

The setup of HPSG II is summed up in figure 1. The usual symbols for description language 
operators are used: conjunction (A), disjunction (V), negation (->), and implication (— >). Addi- 
tionally, type assignment, path equality, and path inequality are noted as "=", and 
respectively. 



Descriptions — ► Sorted feature structures — > Abstract linguistic object 

( ^ - I a v -il Interpretation One-to-one 
\ ' I ' ' / Correspondence 

Figure 1: The setup desired in HPSG II 



Several logics have been proposed to provide the formal foundations for this setup. Basically 



8 Totally well-typed means that a) "what attribute labels can appear in a feature structure is determined by 
its sort; this fact is the reflection within the model of the fact that what attributes ... an empirical object has 
depends on its ontological category." and b) "every feature that is appropriate for the sort assigned to that node 
is actually present." (HPSG II, p. 18) 

9 "A feature structure is sort-resolved provided every node is assigned a sort label that is . . . most specific in 
the sort ordering." (HPSG II, p. 18) 

10 It is not uncontroversial whether total models of complete linguistic objects are what is needed for linguistics. 
Problems for such total models arise for example in the analysis of coordination (cf. the weak coordination principle 
and fn. 14 on p. 400 of HPSG II). 

11 In HPSGII the term attribute-value matrix (AVM) is used instead of description. For easier comparison of the 
different setups, we will only use the term description. Furthermore, attribute and feature are used synonymously 
throughout the paper. The same is true for type and sort, except in the use of typed feature structure (cf. Carpenter 
(1992)) vs. sorted feature structure (cf. HPSGII). 

12 The values of two attributes are token identical iff the two paths point to the same node. The other common 
identity notion is type identity: Two feature structures are type identical iff they are of the same type, the same 
attributes are defined on both feature structures, and the feature structures which are the values of the attributes 
are type identical. 
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there are two families of logics dealing with this task: the Kasper- Rounds logics and the 
Attribute- Value logics 14 . Two representatives of these families are of particular interest for the 
following discussion, since they also have been used to construct computational systems for the 
implementation of HPSG grammars: the Kasper-Rounds logic defined in Carpenter (1992) on 
which the ALE system is based, and the Attribute- Value logic of King (1989) which underlies 
the Troll system. Figure 2 shows the setup proposed in Carpenter (1992). The descriptions of 
Carpenter (1992) describe typed feature structures, which model partial information. 



Descriptions — ► Typed feature structures — ► Partial information 

f _ _/_ I a \j) Interpretation One-to-one 
V i ir- | j v j Correspondence 

Figure 2: The setup of Carpenter (1992) 

This setup differs from the HPSG II desideratum described above. Carpenter (1992) uses typed 
feature structures to model partial information. Presumably there is a further level, in which 
the partial information is related to the linguistic objects, which is left undefined. Since the 
typed feature structures model partial information they cannot be total representations like the 
sorted feature structures of HPSG II. The typed feature structures used as models in Carpenter 
(1992) are therefore not required to be totally well-typed or sort-resolved. In the HPSG II setup 
"partial information" plays no role; the linguistic objects themselves are modelled by the sorted 
feature structures. This difference has consequences for the description language of Carpenter 
(1992). Moshier and Rounds (1987) show that in the setup of a Kasper-Rounds logic, full classical 
negation as part of the description language destroys subsumption monotonicity on typed feature 
structures which Carpenter and others claim has to be upheld if feature structures are to model 
partial information. In the discussion of recursive type constraints in chapter 15 of Carpenter 
(1992) (p. 233), Carpenter states that even for the formulation of implicative constraints with 
type antecedents (i.e. type negation) subsumption monotonicity cannot be achieved. 15 The 
description language of Carpenter (1992) therefore only contains path- inequations, a weaker 
form of negation. 



Descriptions — > Concrete linguistic objects 

(~ = | A V — ') Interpretation 

Figure 3: The setup of King (1989) 



The setup of King (1989), displayed in figure 3, at first sight also differs from the HPSGII 
desideratum. The most apparent difference is the missing model level. The descriptions are 
directly interpreted as being true or false of linguistic objects, not of feature structures which 
stand in a one-to-one relation with linguistic objects, as in HPSGII. Apart from the philosophical 
consequences (which will not be discussed here) this gap between HPSGII and King (1989) can 

13 Cf. Rounds and Kasper (1986), Moshier and Rounds (1987), and Carpenter (1992). 
14 Cf. Johnson (1988), Smolka (1988), and King (1989). 

15 Note that the theories in an HPSGII architecture are formulated using implications on types; in fact, even 
stronger implicative statements with complex antecedents are used. We will see on pp. 15 of section 3.2.1 how 
certain stronger implicative statements can be reformulated as implications with type antecedents by encoding 
additional information in the signature. 



ON IMPLEMENTING AN HPSG THEORY 



7 



be bridged. Since the models of linguistic objects in the first approach and the linguistic objects 
in the second are both total (i.e. the sorted feature structures of Pollard and Sag are defined 
that way and the linguistic objects of King are total since they are objects) there are no formal 
consequences to the dropping of the modelling level in King (1989). As proof of this King 
(1994) shows that a modelling level can be introduced without changing the rest of the logic. 
The second difference between the HPSG II desideratum and the King logic is that HPSG II talks 
about abstract linguistic objects while the King setup uses concrete linguistic objects 16 . King 
(1994) shows how this gap can be bridged as well. The logic proposed in King (1989) therefore 
can be used to provide the setup desired in HPSG II. 

The difference between the two logics becomes clearer, when we take a closer look at how 
descriptions are interpreted in each setup. 



Syntax — ► Semantics 

Interpretation 

conjunction of descriptions set intersection 
disjunction of descriptions set union 

negation of descriptions set complement 

Figure 4: Set theoretic interpretation of description language expressions in King (1989) 



In King (1989) descriptions are given a set theoretic interpretation: The interpretation of a 
description is a set of objects. Conjunction, disjunction, and negation as operations on descrip- 
tions are interpreted as set intersection, set union, and set complement, respectively. In such a 
set theoretic setup, an object satisfies a description iff it is in the denotation of that description. 



Syntax — ► Semantics 

Interpretation 

conjunction of descriptions unification 

disjunction of descriptions eliminated by lifting 

disjunction to top level 

Figure 5: Interpretation of description language expressions in Carpenter (1992) 



In Carpenter (1992), the interpretation of a description is a set of typed feature structures. 
Conjunction of descriptions is interpreted as unification of feature structures and disjunction 
is eliminated by lifting it to the top level. The satisfaction relation is defined directly between 
feature structures and descriptions without using set theoretic denotations (cf. p. 53 of Carpenter 
(1992)). 

Now that we have introduced the two logics, we can turn to the computational systems which 
are based on them. The ALE system uses the setup and the description language of Carpenter 
(1992). Additionally feature structures in ALE are required to be totally- well- typed. The main 



Abstract linguistic objects are also called linguistic "types", and the term linguistic "tokens" is used for 
concrete linguistic objects. This usage of the term "type" has nothing to do with the types as part of the 
signature of a typed feature logic. In order to avoid confusion, the terms "types" and "tokens" meaning abstract 
and concrete will not be used in this paper. 
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difference between Carpenter (1992) and the ALE system is that theories in ALE are expressed 
using a relational extension 1 of the description language, which is outside of the defined feature 
logic. 18 

The King (1989) logic supplies the Troll system with an interpretation of a signature and a 
description language which is adequate for HPSGII. However, there are some differences between 
the logic and the computational system: Just as in the ALE system, a relational extension of the 
description language is used to express linguistic theories. Also, currently only the conjunctive 
part of the description language is part of Troll. As supplement to the King setup, typed feature 
structures are introduced as normal form descriptions. Note that the typed feature structures 
here are part of the syntax, not of the semantics as in the Carpenter approach. 

There are several consequences of the theoretic and computational setups just introduced for 
some commonly used terminology. When two descriptions are conjoined in Troll, unification is 
used to calculate a normal form description, the denotation of which is the intersection of the 
denotations of the descriptions conjoined; i.e. unification is an operation on the syntax and plays 
no theoretic role. In ALE, unification is the interpretation of the conjunction of descriptions, 
i.e. it is the semantics of a syntactic operation. 

The same division into syntax and semantics applies to subsumption. In ALE, subsumption 
is a relation that makes statements about the complexity of the feature structures serving as 
semantic representation. If we try to add subsumption to the King setup (or that of HPSGII), 
we note that subsumption does not make sense as relation on objects (or the sorted feature 
structures) which are on the semantic side, since these are total representations. The only place 
for subsumption in the King setup therefore is on the syntactic side as a relation on descriptions. 
The interpretation of the subsumption relation on descriptions is the subset relation on the 
denotations of the descriptions. Note, however, that the subsumption relation is no proper part 
of the description language of the logic of King (1989). Summing up the last two paragraphs, 
neither unification nor checking for subsumption is part of the description languages of the two 
logical setups. In the discussion of the lexical rule mechanism in section 4.1.3 we will come back 
to this. 

In the rest of the paper we will assume the ontological setup and terminology of King (1989). 
The following feature logic terminology is used throughout the paper: T is the least constrained 
type denoting all objects; _L is the inconsistent type denoting the empty set. Minimal types 
are the types which have no subtypes except for _L, e.g. the most specific types, sometimes also 
called varieties or species. Since nothing of theoretical interest relies on the feature structures 
as normal form descriptions, feature structures will not appear on stage in the rest of the paper. 
Only when specifically speaking about the logic of Carpenter (1992) or the ALE system, will 
the Carpenter setup and its terminology be used. 



17 For a discussion and the formal definition of a relational extension of a constraint language cf. Jaffar and 
Lassez (1987) and Hohfeld and Smolka (1988). 

18 The different possible ways of expressing a theory are discussed in section 3.2. 
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3 The HPSG architecture: A linguist's view on the feature logic 
toolkit 

After the ontological primer, we can now go on to discuss the HPSG architecture based on this 
setup. An HPSG theory consists of two ingredients: the declaration of the domain of linguistic 
objects in a signature (consisting of the type hierarchy and the appropriateness conditions) 
and the formulation of constraints on that domain 19 . The perspective taken in the following 
discussion is always that of a linguist wanting to know what consequences each formal setup has 
on the formulation and implementation of an HPSG-style grammar. The reader interested in 
the mathematical definition and properties of the architectures is referred to the feature logic 
literature, in particular King (1989), Carpenter (1992), King (1994), and Gotz (1994). 

3.1 Declaring the domain of a grammar 

From the viewpoint of linguistics, the signature introduces the domain of objects the linguist 
wants to talk about. The theory the linguist proposes for a natural language distinguishes 
between those objects in the denotation which are part of the natural language, and those which 
are not. First, we will take a look at the signature. The possibilities for writing theories are 
dealt with in the next section. 

The signature serves as the data structure declaration for the linguistic theory. It consists of 
a type hierarchy and appropriateness conditions. The type hierarchy introduces the classes of 
objects the grammar makes use of, allowing us to refer to the classes by using the types as 
names. The appropriateness declarations define which class of objects has which attributes with 
which values. 

At which types attributes can be introduced and the exact interpretation of the type hierarchy 
is subject of debate. Two interpretations of a type hierarchy are common: ALE is based on an 
open world interpretation, while HPSG theory and Troll use a closed world interpretation. 

Briefly said, a closed world interpretation makes two assumptions: every object in the denotation 
of a non-minimal type is also described by at least one of its subtypes; and every object is of 
exactly one minimal type. An open world interpretation makes no such assumptions. 

Once we commit ourselves to a closed world interpretation, more syntactic inferences can be 
made. While both interpretations allow the inference that appropriateness information present 
on a type gets inherited to its subtypes, we can now additionally infer the appropriateness 
specifications on a type from the information present on its subtypes. 

In the implementation, the information resulting from these additional inferences allows us to 
specify less information by hand and enables us to express constraints on the interdependence of 
attribute specifications. 20 Besides the gained expressive power, this leads to syntactic detection 
of more errors as well as an increase in efficiency 

The following example from the implemented grammar illustrates the additional expressive 

The different linguistic motivations behind the constraints (e.g. grammatical principles, lexical information) 
and the possible ways for expressing these are discussed in section 4. 

20 Note the correspondence with the so-called feature cooccurrence restrictions of Gazdar, Klein, Pullum, and 
Sag (1985). Cf. Gerdemann and King (1993) and Gerdemann and King (1994) for a detailed investigation of this 
issue. 



10 



W. DETMAR MEURERS 



power gained in a closed world interpretation. We want to capture that non-finite verbs are 
never inverted. 

[VFORM n.fin] — > [iNV minus] 

Figure 6: The implication to be captured 

It is not possible to directly encode the intended relationship between VFORM and INV in the 
signature of the feature logics introduced. However, under a closed world interpretation the 
regularity can be encoded in a signature with a slightly modified type hierarchy. 21 Figure 7 
shows the type hierarchy below verb. Two new subtypes are introduced. 22 



verb 



VFORM vform 
INV bool 



fin_v 



VFORM fin 



n_finju 



VFORM n.fin 
INV minus 



Figure 7: The subtypes of verb (a subtype of head) 
Under a closed world interpretation the following inferences hold. 



(a) 


fin_v 


<— > 


[VFORM fin] 


(b) 


n-firi-V 


<— > 


[VFORM n.fin 


(c) 


n_fin_v 




[iNV minus] 


(d) 


[iNV plus] 




[ VFORM fin] 


(e) 


[VFORM n.fin 




[iNV minus] 



Figure 8: Some inferences under a closed world interpretation 
The originally desired implication repeated as (e) is deduced from (b) and (c). 



21 The method used here for encoding implicative statements with complex descriptions as antecedent in the 
signature is discussed in detail in section 3.2.1. 

22 Once the subtypes of verb are introduced, the original VFORM attributes could be omitted without loss of 
information. However, this would change the original type hierarchy (with its linguistic motivation) even more, 
making it necessary to reformulate every reference to the verb-form in the whole grammar. In any case, this issue 
does not change anything regarding the fact that the implication (d) in figure 8 will only be obtained under a 
closed world interpretation. 



ON IMPLEMENTING AN HPSG THEORY 



11 



Under an open world interpretation only the inferences in figure 9 are made: 

(a) fin_v — > [VFORM fin] 

(b) n_fin_V — > [VFORM n_fin] 

(c) n-fin_V — > [iNV minus] 

Figure 9: The inferences under open world interpretation 

Compared to the inferences made under a closed world interpretation, under an open world 
interpretation the " direction in (a) and (b) is missing . Therefore the originally desired 
implication (figure 6) cannot be deduced. Additionally the inference (d) of figure 8 is missing. 
To still get the desired results one therefore has to ensure the " direction of (a) and (b) by 
hand; i.e. additional specifications on the lexical entries and the principles are necessary. The 
same is true for the implication (d). Under an open world interpretation the full set of inferences 
of figure 8 (which include the originally desired implication of figure 6) therefore only hold for 
the descriptions bearing the additional specifications; i.e. under an open world interpretation 
it is not possible to ensure that the full set of inferences will always be made for every object. 
Regarding the theoretical level, this can lead to incorrect analysis. In the computational systems 
based on an open world interpretation (e.g. ALE) this has the effect that the desired inferences 
will not be made for feature structures resulting in processing. The missing inferences in such 
computational systems therefore result in possibly incorrect, but in any case slower analysis. 

The second variation in the concept of a signature concerns the appropriateness conditions. The 
feature introduction condition (FIC) of ALE demands that for every feature there is a unique 
least specific type at which this feature is introduced. 

In the grammar implemented this turns out to be troublesome. As an illustration let us look 
at the signature definition of head objects. Figure 10 shows the type hierarchy as motivated by 
the linguistic theory. 23 



head 




Figure 10: The type hierarchy below head 



The problem arises with the introduction of the case and declension attributes, since CASE and 
DECL are appropriate for adjectives, nouns, and determiners, but not for markers and verbs. 
To satisfy the feature introduction condition, a new type adj_noun-det as subtype of head and 
with subtypes adj, noun, and det needs to be introduced for which the two attributes CASE and 



As before and throughout the paper, the most general type is on top. Note that Carpenter's hierarchies are 
drawn the other way around: his most general type is at the bottom. 
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DECL are appropriate. 




Figure 11: A first step towards satisfying the FIC 

However, in the resulting structure in figure 11 the types subst and adj_noun_det do not have a 
unique greatest lower bound. This violates the formalization of a type hierarchy as finite bounded 
complete partial order (cf. Carpenter92). Therefore, an additional type adj_or_noun needs to 
be introduced. Figure 12 shows the final type hierarchy together with the appropriateness 
information for adj-noun-det. 24 



head 




verb prep adj_or_noun det marker 




Figure 12: A type hierarchy satisfying the FIC for CASE and DECL 

The feature introduction condition is part of the Carpenter (1992) logic and the ALE system. 
It plays no role in the logic of King (1989) or the Troll system. 25 



The type hierarchy actually used in the implementation is more complicated still, since a type non_noun as 
subtype of head has to be introduced. This is necessary to introduce a type for lists of nominal signs, which 
is needed as constraint on the auxiliary entries and the output of the PVP extraction lexical rule in HN. Cf. 
section 4.1.3, p. 37 for a discussion. 

25 King and Gotz (1993) show that the feature introduction condition can also be eliminated within the logic of 
Carpenter (1992). 
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3.2 Constraining the domain 

Now that we have seen how the domain of linguistic objects is defined by the signature, we are 
ready to discuss how the theory, i.e. the constraints making up the grammar can be expressed. 
The theory divides the domain of objects specified by the signature into admissible ones, which 
are part of the natural language described, and those which are not admissible, i.e. not part 
of the natural language. In linguistic terms the constraints making up the grammar are the 
principles (e.g. the Immediate Dominance Principle (IDP), the Head Feature Principle (HFP), 
the Nonlocal Feature Principle (NFP), the Semantics Principle (SemP)) and the specification of 
the lexicon. The architectures of HPSG II and the various systems differ considerably regarding 
the question of how the constraints are expressed. Basically there are two main groups: those 
description languages directly constraining the domain of linguistic objects, and those in which 
relations on linguistic objects are expressed. 



3.2.1 Group 1: Directly constraining the domain of linguistic objects 

In HPSG II and the TFS system the grammatical constraints are expressed as statements about 
the domain of linguistic objects. The simplest implicative form (henceforth called type definition) 
is depicted in figure 13. It has the following interpretation: if something is of type t, then it has 
to satisfy the description D. 

t -» D 

Figure 13: The type definition: a simple implicative constraint 

In addition to the type definitions, HPSG II also uses a stronger implicative statement of the 
form displayed in figure 14. 

C -> D 

Figure 14: The object definition: an implicative statement with possibly complex antecedent 

The intended interpretation is that if something satisfies the possibly complex description C it 
also has to satisfy D. We will call the implicative constraints (including the type definitions) 
object definitions. In writing a grammar one usually wants to impose constraints on a certain 
group of objects (those in the denotation of the antecedent) and not on all objects (in which case a 
non-implicative statement would do). Therefore, object definitions are the main building blocks 
of linguistic theories in the HPSG architecture. As an example, take the HFP as formulated in 
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the appendix of HPSGII: 



phrase 



DTRS headed- struc 



SYNSEM|LOC|CAT|HEAD 

DTRS | HEAD-DTR| S YNSEM | LOC | CAT | HEAD 



Figure 15: The Head-Feature Principle of HPSGII 



The complex description 



phrase 



DTRS headed-struc 



is the antecedent of the implication. Note 



that using the type phrase as antecedent is not enough, since the HFP is only supposed to 
apply to phrases dominating headed structures. The HFP constraint demands that all objects 
of type phrase which have a DTRS attribute with a headed-struc object as value, also have to 
be described by the consequent, i.e. satisfy the description that the HEAD values of the object 
and that of its head daughter are token-identical. 

A closer look at the antecedents of implicative constraints 

To get an idea of the complexity of the description language, we need to distinguish between 
different kinds of antecedents of implicative constraints. Figure 16 displays three classes of de- 
scriptions, which can function as antecedents of implicative statements in the order of increasing 
complexity. 



1. simple type description (e.g. t) 

2. complex description with type assignments (e.g. 



Y v 
Z w 



) 





X 


i 


u 


■g- 


Y 


i 




t 









3. complex description with type assignments and path equalities (e.£ 

Figure 16: Three classes of descriptions 



The simplest implicative statements are the type definitions, which only allow types as an- 
tecedent (class 1). One step up in complexity, complex feature structures which specify no 
structure sharing can be used as antecedents (class 2). Finally, in the most complex type of 
implications the antecedents are allowed to specify structure sharing information as well (class 
3). 

The implicative statements in HPSGII are mostly of class 2. However none of the computational 
systems allow the user to specify complex antecedents; only type definitions are supported. 26 



26 This also applies to the systems in which a theory is expressed on the relational level (the group 2 setups) since 
the method described in section 3.2.2 for translating theories which are expressed as constraints on the domain 
(group 1) into theories which are expressed on the relational level (group 2) is restricted to type definitions as 
well. Therefore, until other general techniques for expressing HPSGII-style theories on the relational level are 
defined which might allow us to express implicative constraints with complex antecedents, both computational 
setups are restricted to type definitions. 
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Because of this discrepancy in expressive power, it is interesting to note that the implicative 
statements with complex antecedents used in HPSG II can be expressed as type definitions by 
modifying the signature, i.e. a new type can be introduced so that it has the same denotation 
as a given class 2 description. To see how this encoding works, let us first take a closer look at 
the appropriateness conditions (ACs). 

In section 3.1 we had characterized ACs as part of the data structure declaration, the declaration 
of the domain in more logic based terminology. This means, the ACs take part in defining the 
domain over which the theory is formulated. The objects not satisfying the ACs are not in 
the domain. On the other hand, ACs can also be understood as rather weak constraints on 
the domain of objects as defined by the type hierarchy alone. 27 They restrict the values of the 
immediate attributes of a type without specifying structure sharing. Under this interpretation, 
the domain over which the theory makes statements also contains objects which do not satisfy 
the AC. However, while the one-level-only condition does not restrict the set of descriptions 
which can be encoded in the signature definition of a type, the no-structure-sharing condition 
is a real restriction. Descriptions specifying structure sharing cannot be encoded in a type by 
modifying the signature only. To encode a class 3 description in a type, one therefore additionally 
has to specify a constraint on the new type as part of the theory in order to express the structure 
sharing conditions on its attributes. 28 

Encoding the information of a class 2 description D in the signature works in the following way: 
A new type is introduced as subtype of the type of D. 29 The type specifications on the first level 
of attributes of D are encoded in the ACs of the new type. If D contains descriptions of further 
levels of attributes, new subtypes have to be introduced to mediate the information. Note that 
this introduction of additional types for each additional level quickly leads to an explosion of 
the type hierarchy. 

To illustrate this mechanism let us look at an example from HN. 30 In HN every auxiliary is 
supposed to bear an argument raising specification, which in its basic form is shown in figure 17. 



COMPS 



SYNSEM|LOC|CAT 



HEAD verb 
VAL|COMPS \T\ 



Figure 17: Argument raising specification on a non- finite auxiliary [valence value shown) 



There are two options for encoding this in the grammar. Since we are dealing with lexical 
specifications, the methods for expressing generalizations over classes of lexical entries could be 

27 Note that ACs are inherited from a type to its subtypes, allowing generalizations to be expressed in a nice 
hierarchical way independent of how the theory is formulated. 

So far no HPSG theory to our knowledge makes use of class 3 antecedents for implicative statements. This 
means that currently only the class 2 antecedents, which can be encoded without manipulating the theory, i.e. by 
changing the signature only, are linguistically motivated. 

29 A complication arises, if D describes objects of different types. In this case, a new subtype has to be introduced 
for each of the types of object described by D. 

For this and the following examples I assume the signature of HN and the grammar implemented. It closely re- 
sembles the one in the appendix of HPSG II with the modifications of Chapter 9. However, note that all valence at- 
tributes (e.g. COMPS) take a list of signs as their value, not a list of synsems. The order of the valence lists of HN is 
inverted in the grammar implemented, i.e. valence lists look like {most- oblique- element . . . least- oblique- element ) . 
This order is used in the examples of this paper as well. A discussion of the motivation behind this change is 
given in section 5.1. 



16 



W. DETMAR MEURERS 



used. These are dealt with in section 4.1. The other possibility for attaching the argument raising 
specification in figure 17 to auxiliaries is to use the general mechanism for expressing grammatical 
constraints. To do this, the following object definition can be added to the grammar: 



word 



SYNSEM|LOC|CAT|HEAD „ er J AUX P H 



SYNSEM|LOC|CAT|VAL|COMPS 



SYNSEM|LOC|CAT 



HEAD verb 
VAL|COMPS \T\ 



□ 



Figure 18: An object definition to attach the argument raising specification 

To rewrite this object definition as type definition, a new subtype of word (call it aux-word) 
needs to be introduced. We want it to have the same denotation as the complex antecedent 
of the implication in figure 18. Assuming the signature definitions given in the appendix of 
HPSGII as basis, under a closed world interpretation the following flood of signature changes 
and new definitions is necessary to achieve that. 



word > non-aux-word, aux-word. 

SYNSEM non-aux-synsem 



11. 



non-aux-word L 

SYNSEM aux-synsem 

aux-word - 



b) synsem > non-aux-synsem, aux-synsem. 

LOC non-aux-loc 



1. 



11. 



non-aux-synsem 

LOC aux-loc 

aux-synsem - 



loc > non-aux-loc, aux-loc. 

j CAT non-aux-cat 

non-aux-loc - 

CAT aux-cat 



11. 



aux-loc 



d) cat > non-aux-cat, aux-cat. 

HEAD non-aux-head 



1. 



11. 



non-aux-cat 

HEAD aux-verb 

aux-cat - 



e) 


head > subst, 


non-aux-head. 


f) 


subst > verb, 


non-aux-subst. 


g) 


non-aux-head 


> non-aux-subst, func. 


h) 


non-aux-subst 


> non-aux-verb, prep, adj, noun. 
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i) verb > non-aux-verb, aux-verb. 

; AUX minus 



non-aux-verb 



aux-verb 



AUX plus 



Figure 19: Additional signature definitions to introduce the type aux-word 



Two subtypes are introduced for each of the types word, synsem, loc, and cat in order to me- 
diate the AUX specification from the sign-level to the head level. The hierarchy below head is 
more complicated. For easier comprehension it is displayed in graphical notation below. The 
corresponding type hierarchy of HPSG II from which this new hierarchy is derived, was already 
presented in figure 10. 




Figure 20: The resulting type hierarchy below head 

Clearly these linguistically unmotivated changes to the type hierarchy in order to lift information 
to the "surface" , i.e. the top level of an implication, is nothing that can be asked of a linguist 
encoding a grammar. One could therefore consider eliminating the hierarchical structure of the 
models of linguistic objects and return to simpler, flat models. Until there is linguistic evidence 
against the hierarchical structures 31 it is better motivated though, to extend the computational 
systems so that complex antecedents can be expressed directly. Introducing general negation 
into the formalism, would allow any complex antecedent to be expressed directly. However, 
while this might turn out to be possible in some underlying logics, losing the type backbone to 
the constraints (the type antecedents as "triggers" for the implicative constraints) causes sig- 
nificant computational problems and no system currently provides such an architecture. In this 
situation, the technique introduced above for encoding complex descriptions in types looks like a 
valuable method after all. An automated version of the encoding process could be included in a 
compilation step applying after the writing of the grammar. Thus the linguistically unmotivated 
mutation of the signature would also be hidden from the eyes of the linguist. 



31 We here ignore the problematic issue of lexical hierarchies (cf. Chapter 8 of Pollard and Sag (1987)). A short 
discussion of these hierarchies is included in section 4.1.2. 
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Recursivity 

After looking at the antecedents of implicative constraints, we now turn to the consequent of 
the implications to see where the expressive power to make recursive statements (necessary to 
work with lists and sets) comes from. 

TFS allows a more complex version of type definitions, which is displayed in figure 21. 

t -» (D & E 1 k ... k E n ) 
Figure 21: The extended type definitions of TFS 

Just as with simple type definitions, the extended type definition above is true of those objects 
of type t which are also described by D. Additionally, each of the new descriptions Ei appended 
with "&" 32 have to be satisfiable. In other words: there must be objects in the denotation of 
each description Ei. These extended type definitions enable us to state recursive definitions, 
since each of the objects in the denotation of E-i has to satisfy the constraints imposed on its 
type. If an Ei describes objects of the type t that is being defined (= the antecedent of the 
implication), one obtains a recursive statement. 

It is possible to make sense of the meta operator operator "&" within the description language. 
Following A'it-Kaci (1984), one can add extra attributes ("junk slots") to linguistic objects 
to "store" additional objects. The descriptions which were added using the extra- logical "&" 
operator now only have to be added to the theory as descriptions of the objects residing in the 
newly introduced attributes. 33 Applying this junk slot encoding technique to the definition in 
figure 21, we introduce a list valued attribute STORE as appropriate for type t. The resulting 
description language encoding of figure 21 is displayed in figure 22. 

t — »■ (D A [store <e u ...,e„ >]) 
Figure 22: Extended type definitions expressed using the description language only 

Beside using the additional descriptions housed in the junk slot attribute to describe ordinary 
linguistic objects, one can also use statements like that in figure 22 to formulate recursive 
relations on linguistic objects at the same level at which the objects are described. The additional 
junk slot attribute then also allows calls to relations to be attached to descriptions of linguistic 
objects without the use of a meta operator "&" . Note that when a recursively defined relation 
is used as description of an object's attribute value, the object will bear the full proof-tree in 
the attribute. 

As example for the definition of a recursive relation at the level of the description language, the 



The "&" is not to be confused with the conjunction "A" of the description language, which is interpreted as 
set intersection of the denotations of the conjuncts. 

33 This applies to the TFS system as well. The "&" operator in TFS can therefore be seen as surface syntax 
for the user making it unnecessary to worry about introducing additional attributes as junk slots to store the 
additional descriptions which one wants to test for satisfiability. 
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definition of the standard append relation on lists 34 is shown in figure 23. 
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Figure 23: Defining append objects 

The constraint in figure 23 defines what kind of append objects are admissible. The description 
"append 1 (i.e. a call to append, possibly as part of some other description) denotes a set of 
append objects having their attributes constrained as defined. 

While HPSG II is not committed to a certain way of expressing recursive statements, an alter- 
native possibility often found in the HPSG literature is to use definite clauses as a relational 
extension of the description language. Note that in contrast to the encoding of relations dis- 
cussed above, the use of definite clauses described here is outside of the feature logic and it is 
not formally defined. The definitions of the definite clauses are allowed to be recursive, yielding 
the expressive power we were looking for. To use the relations thus defined, the calls to the 
definite clauses are attached to the implicative statements just like the additional descriptions 
are in TFS. 



C -► (D & reh{E lu ...,E u ) & ... & rel n (E nl , . . . , E nj )). 
Figure 24: A type definition with attached relational constraints 35 

Figure 24 only shows the use of relations, not their definition. Contrary to the setup used in 
TFS, the definition of the relation itself is specified on a level different from the level of the 
grammatical constraints defined in figure 24. Because the definite clause relations are not part 
of the description language, the calls to the definite clauses need to be added to the descriptions 
using the extra-logical operator "&" . Note that for the same reason it is not possible to include 
the calls to the definite clause relations in a description as it was done with the help of the junk 
slot technique for the relations formulated within the description language. Definite clauses 
are defined as in PROLOG, the only difference being that while in PROLOG definite clauses 
over first order terms are formulated, here definite clauses over feature descriptions are used. 
Figure 25 shows the definition of the append relation as part of the relational extension of the 



34 The append relation specifies the third argument to be the concatenation of the two lists passed as first and 
second argument. 

35 C, D, and the E xy are descriptions. 
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description language. 

a) append(<>, [7], |T|). 

b) append(< [7] | [JJ >, [7J, < [7] | [7J >) := append(0, [7J, 0). 

Figure 25: Denning the append relation 

Here append, being a three place relation, denotes the set of triples of list objects, which satisfy 
the definition given. 

This ends the discussion of the first group of setups, in which the theories directly constrain the 
domain. 

3.2.2 Group 2: Expressing relations on linguistic objects 

The second group - represented by systems like ALE, CUF, and Troll - takes the concept of 
the relational extension of the description language just described, and makes it the only way 
to express the grammatical constraints of the theory. Relations over objects are formulated. 
Unlike in the group 1 setups, the objects cannot be constrained directly. 36 

The result is a setup with a clean distinction between the description language, and the relational 
extension of that language: the description language only serves to describe the objects which 
can be arguments of the relations. Figure 26 illustrates this setup. 

rel Q (E 01 ,...,E 0i ) : - reh(E u , . . . , E ±j ), . . . , rel n (E nl , . . . , E nk ) 
Figure 26: Two levels of constraints in a definition of the relation relo 

Note that the question of how the constraints making up the theory are expressed is a separate 
issue from the formulation of a signature discussed in section 3.1. Both, group 1 style and 
group 2 style theories are based on an underlying signature. However, as discussed in the 
previous section, the appropriateness conditions of the signature can also be seen as expressing 
weak constraints on a domain defined by the type hierarchy only. Therefore, even in a group 2 
system, i.e. in a system in which the theory is expressed exclusively on the level of a relational 
extension of the description language outside of the feature logic defined, some grammatical 
constraints can be expressed inside of the logic by encoding them in the signature. 

Definite clauses are not the only relevant way to express relations. ALE and Troll offer a parser, 
which allows the formulation of phrase structure (PS) rules as relations on objects of a local 
tree. The phrase structure rules function as backbone to which the grammatical constraints 
expressed in definite clauses are attached. Such a setup was used for the implementation of HN. 

36 ALE additionally offers the possibility to specify type definitions. Therefore ALE belongs to both group 1 and 
group 2 architectures, i.e. it can be used to formulate grammars in two different ways: by specifying constraints 
on the domain and by writing down relations on objects. However, currently the formal status of such hybrid 
setups is rather unclear. In the grammar implemented only the relational level is used to express the linguistic 
theory. 



ON IMPLEMENTING AN HPSG THEORY 



21 



The method used to encode the HPSG theory in a phrase structure backbone setup while at 
the same time trying to preserve the character of the original theory is discussed in sections 4.2 
and 4.3. 

The difference between the two groups of architectures is reflected in the queries which can be 
formulated in those architectures. While in the first group one queries with a description to see 
whether that description describes any objects, in the second group one asks whether a relation 
holds between objects. 

So far we have not yet explained, how an HPSG grammar can be expressed in a group 2 setup. 
The HPSG II theory is based on an architecture in which the domain can be directly constrained 
by the theory (group 1). Still, for computational reasons, almost all computational systems use 
a group 2 setup. It is therefore interesting to take a look at how a setup like the first can be 
modelled in a system of the second group. 

Modelling group 1 behavior in a group 2 setup 

What does it need to get the feel of a group 1 setup in a group 2 system? For the linguist wanting 
to encode a grammar it boils down to two things: How are the constraints making up the theory 
specified? and How is the system queried? Something we need to integrate into a group 2 
setup to get a group-l-like behavior regarding the constraint specification is the hierarchical 
organization of constraints. An object of a certain type has to satisfy all the constraints on 
objects of that type and all the constraints on objects of any of its supertypes. Regarding the 
queries, we want to be able to ask if a description is satisfied by any objects which satisfy the 
theory. 

If we restrict ourselves to implicative constraints with type antecedents 37 , a general solution is 
to introduce three relations for every type. One relation is needed to encode the constraints 
defined for the type, i.e. to specify the type and to encode the consequent of the type definitions 
for the type which are part of the theory. A second relation collects all constraints on the type 
(by calling the first relation) and its subtypes. Finally a third relation is responsible for adding 



This opens up a new area of application for the technique for encoding complex antecedents of implicative 
constraints as type antecedents by modifying the signature discussed in section 3.2.1 on pp. 15. 
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the constraints on the supertypes of the type. Let us illustrate this method with an example. 
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Y T 
Z T 
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Figure 27: The example signature 

As usual, the signature definition in figure 27 declares a domain of objects. The theory in figure 
28 specifies which objects are admissible. It consists of two implicative constraints with types 
as antecedent. 



[z b] 



Figure 28: The example theory in a group 1 setup 

In figure 29 the group 2 theory with the three relations for each type is listed. 38 The relation 
name subscripts and the names of the lines in which the relations are defined have the following 
interpretation: "h" stands for the hierarchy of constraints below the type (including the type 
itself), "c" for the constraint on the type, and "t" for all constraints on the type including those 
inherited. 



1. 


h) 


Them) 


a h (rrj). 


2. 


t) 




- T h( {±\a )• 
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- a c (r7J), ( b h ([T]); c h ([7}) ) 
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3. 


t) 


b t (0) : 


-T ft ([i]6). 



A notation reminiscent of PROLOG is used for the relational level: disjunction is noted as ";" and conjunction 
by The full set of three relations per type is only displayed to illustrate the general mechanism. In an 

implementation several of the relations defined could be eliminated, for example by partially executing the definite 
clauses at compile time. 
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h) b c (0). 

c) b c (6). 

t) c t (Q) :- T h (0c). 

h) c h (0) :- c c (0), ( d h (0); e ft (0) ). 



c) c c ( c A 



x 0[z 0] 

Y 



=- b t (0). 



t) d t (0) :- T h ([T]d). 
h) d ft (0) :- d c (Q). 



c) d c ( d A 



)• 



t) e t (Q) :- T fc ([7]e). 
h) e^(0) :- e c (0). 
c) e c (e). 



Figure 29: The relations encoding the example theory in a group 2 setup 



Take for example the encoding for the type c. The relation c c imposes the description language 
constraints for type c on the argument of the relation. Here the link between relational level 
and the description language level is made. The argument of the relation is assigned the correct 
type, and the consequent of the type definition for c (cf. group 1 theory in figure 28) is conjoined 
to that. No inherited constraints are specified here, only the constraints directly imposed on the 
type. Whenever in a group 1 theory a type restriction is specified, in the corresponding group 2 
theory, in the type's c-relation - where all description language restrictions are encoded - a call 
to the type's t-relation is used. For example, the specification [x|z b] in the type definition for 
type c is encoded in the relation c c as a call to the relation b^. This ensures that all constraints 
on the type, including the ones inherited, are applied whenever a type restriction is specified. 
Note that the appropriateness conditions for the argument of a t-relation are preserved under 
this approach, since every c-relation ensures that the argument is assigned the correct type. 

The relation c/j references the constraints on type c which were collected in c c and adds the 
constraints defined for the subtypes of c all the way down to the most specific subtypes. In 
the example there is one more level to the most specific types d and e. This step ensures that 
every object in the denotation of the type c also is in the denotation of one of the most specific 
subtypes of c, basically enforcing a limited version of the closed world interpretation introduced 
in section 3.1. 

Finally, the relation ct imposes on its argument all constraints on type c, those directly specified 
for the type, and those inherited. This is done by collecting the constraints for type c from the 
constraint hierarchy all the way from the most general type top down to a most specific sybtype 
of c. 

Summing up, this encoding technique provides us with a general mechanism for transferring 
theories expressed using class 2 implicative statements into an architecture in which a theory 
has to be formulated on the relational level. The "look and feel" of the original formulation 
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is preserved. It is clear that one cannot expect the linguist to re-encode a theory in such an 
awkward way, but such a re-encoding could be done in a automated compilation step transferring 
the grammar written by the linguist into machine friendly code. 

In HPSGII only very few types are actually constrained, i.e. appear as the type of the antecedent 
of an implicative constraint. Also, most currently implemented grammars are only used to 
query for (headed) phrases. The result is that only few relations need to be defined to work 
with the system. Therefore most current implementations of HPSG in a group 2 system do 
not follow anything like the general encoding scheme introduced above. On the other hand, 
an implementation close to the original HPSG theory is only possible if constraints on any 
kind of object can be expressed and queried separately from the top-level signs. Only such an 
implementation can be produced and used by the linguist to provide valuable feedback for a rigid 
and complete formalization of the linguistic theory. Therefore a general automatic translation 
procedure between the linguistic theory and the relational encoding along the lines described 
above seems desirable. It allows working close to the original linguistic theory, enables a modular 
development and testing of linguistic theories, while at the same time supplying runnable code. 39 



4 Modules of an HPSG theory: Special linguistic types of con- 
straints and choices for encoding them 

4.1 Specifying the lexicon 

Like most current HPSG-style analyses, the theory proposed in HN is strongly based on lexical 
specification. In the light of the discussion of the formal background of HPSG in the previous 
sections, the set of constraints which linguists refer to as 'the lexicon' is a collection of implicative 
constraints no different from any other constraint in the grammar (e.g. the principles). Still 
there is a reason why lexical information deserves a second look. In any normal grammar the 
constraints making up the lexicon vastly outnumber the rest of the constraints of the grammar. 
From a linguistic as well as a computational point of view it is therefore interesting to analyze 
how generalizations over this big pool of constraints can be encoded. 

The necessity to express lexical generalizations has long been recognized. Shieber (1986) com- 
ments the situation as follows: "First, we can come up with general techniques for expressing 
lexical generalizations so as to allow lexical entries to be written in a compact notation. . . . 
devices as templates and lexical rules in PATR-II . . . serve just this purpose: to express lexi- 
cal generalizations. As grammars rely more and more on complex lexical encodings (as is the 
current trend in unification-based formalisms) these techniques become increasingly important. 
Second, the formalism can be extended in various ways to be more expressive" (p. 36). We will 
see in this section that Shieber's first point directly carries over to the current HPSG setup. The 
lexical rules are part of the HPSG architecture, and the templates (now often called macros) are 
used in implementations of HPSG grammars. Regarding Shieber's second point, we will show 
that the HPSG formalism is powerful enough to allow for lexical generalizations to be expressed 
within the general constraint formalism. 

Basically, two kinds of generalizations over lexical information are used in HPSG. Instead of 

39 The TFS encoding Meurers (1993) (group 1) was transformed by hand (and sed) into a CUF grammar 
(group 2) along the lines described above. The performance results in CUF were comparable to those of the 
original grammar running under TFS. 
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completely specifying each lexical entry separately, properties of whole classes of lexical entries 
are specified. On the other hand, the existence of certain lexical entries is related to the ex- 
istence of other entries. After an introduction to the basic setup of the lexicon, both kinds of 
generalizations and the formal mechanisms for expressing them are discussed. 

4.1.1 Basics 

In the simplest case, a lexicon is a constraint on objects of type word. 40 Since the set of possible 
lexical objects which are admitted by the linguistic theory need to be constrained, in an HPSG 
grammar there is no way around a statement defining the basic lexicon like that given in figure 
30. 

word -> (Li V ... V U V ... V L n ) 
Figure 30: The basic lexicon: a type definition for the lexical type word 

In the terminology introduced in section 3.2, the figure 30 shows a type definition for type 
word with a disjunctive description as consequent. Each Li is a lexical entry. The effect of this 
implicative constraint is that every lexical element has to be licensed by one of the disjuncts. 
There is no way for a lexical object in a syntactic tree to "sneak through" unconstrained, which 
could be the case if other specifications were included in the antecedent. 

4.1.2 Generalizing over a set of entries 

The question we want to answer in this section is: How can the same information be specified on 
several lexical entries? Referring to figure 30 this comes down to asking: How can information 
be specified on several lexical entries Lj without repeating it in the description of each disjunct. 
There are two possible answers to this question and one theoretically less interesting solution 
which at least avoids syntactic repetition. In the following discussion of the three possibilities, 
we speak of a description C which we want to specify on a set of lexical entries Q. 

Expressing lexical generalizations outside of the lexical type definition 

For the first possibility, one starts with leaving the description C out of the specification of each 
of the Li disjuncts in Q. The provisional result is a lexicon in which the lexical entries in Q 
are too unrestricted. Next, the constraint C is introduced in the theory as an additional object 
definition. The antecedent is specified to describe exactly the objects which are described by 
the lexical entries in Q, i.e. it specifies a property unique to the elements of Q. The consequent 

40 In common HPSG theories word is the only "lexical" type. In case one wants to postulate phrases in the 
lexicon (i.e. for proper names or bare plural noun phrases) a separate lexical type lex-phrase could be introduced. 
The type lex-phrase would be defined as subtype of phrase, with sister-type struc-phrase. The attribute DTRS 
should then be defined as appropriate for struc-phrase instead of for phrase. In the following, this issue is ignored 
and word is assumed to be the only lexical type. Other kinds of lexical types will play a role though in the 
discussion of the so called lexical type hierarchies in section 4.1.2. 

41 If the elements of the set Q do not have a unique property to distinguish its elements from all other linguistic 
objects, such a unique property needs to be artificially introduced in each of the concerned Li specifications in 
the word type definition. However, such a specification naturally contradicts the original intention to specify 
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of the object definition is the constraint C. 

We have already seen an example for this encoding technique in section 3.2.1. The object defini- 
tion of figure 18 (p. 16) was defined to attach the argument raising specifications to auxiliaries. 

Lexical type hierarchies 

The second possibility is to introduce subtypes of the lexical type word and attach the description 
C to the consequent of the type definition of a subtype. Since under a closed world interpretation 
of a type hierarchy every object that is of a type t also has to be described by one of its 
subtypes, the real work under this approach is to make sure that via manipulation of the 
signature we manage to have one of the subtypes of word describe exactly those word objects 
which belong to the set Q (every element of which we want to constrain with C). Like in the first 
encoding proposed above, this requires us to have a group defining property for the elements 
of Q. Following the method described on pp. 15 of section 3.2.1, the description of the group 
defining property then has to be encoded in a type, i.e. a subtype of word. An example for such 
an encoding of a complex description in the signature definition of a type is given in figure 19 
(pp. 16) where the type aux-word is introduced to reference all auxiliary-verb words. Once the 
subtype of word is introduced in the signature, it can function as antecedent of an implicative 
constraint and can specify the lexical entries of Q as displayed in figure 31. Note the conjunct 
C which is the description valid for all disjuncts, i.e. for all lexical entries which are of type 
word-subtype. 



When this approach is used to express several different generalizations over different sets of 
lexical entries, the result is a complex subtype hierarchy below word, which has sometimes been 
called a lexical type hierarchy. 

Comparing this lexical type hierarchy approach to the first proposal, one notes that the encoding 
of a complex description in a type (which complicates the signature and restricts the antecedents 
to class 2 descriptions) is necessary because of theoretical considerations in the lexical type 
hierarchy approach only. This is caused by the fact that in the lexical type hierarchy approach 
a subtype of the lexical type is introduced to get a hold on the lexical entries of the set Q. The 
correct denotation of this subtype has to be ensured by manipulating the signature. In the 
first approach there is no theoretic reason for restricting the implication antecedent to types. 
However, in practice, the restriction of current computational systems to type definitions forces 
the user in both approaches to encode the class 2 antecedents describing the group defining 
property as types. 

Macros as syntactic placebo 

By now, the person interested in implementing a grammar is probably rather desperate. Since, as 
already mentioned several times, current computational systems do not allow the grammar writer 

information without repeating it in each disjunct. It is questionable whether the set of entries does form a natural 
set over which one should express generalizations. The approach in such a case becomes equivalent to (and as 
theoretically uninteresting as) the macro approach described below. 



word-subtype 




Figure 31: Type definition for a lexical subtype 
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to express implications with complex antecedents, both proposals made so far for expressing 
lexical generalizations have a fundamental flaw. They force the implementer to encode additional 
information in the signature, which severely complicates the hierarchy. 42 In order to at least 
avoid writing the same description over and over in the specification of lexical entries, a syntactic 
grouping of information under one name is an emergency solution that is better than nothing. 
The idea borrowed from the template mechanism of PATR-II is to give a name to a set of 
descriptions and to use that name in place of the descriptions. These syntactic abbreviations 
nowadays are usually called macros. The use of the macro mechanism for lexical specification 
is displayed in figure 32. 

word -> ((LiAM) V L 2 V (L 3 AM)) 
Figure 32: An example type definition for the lexical type word using a macro M 

The macro name M abbreviates the description C. It is conjoined to each of the lexical entries 
belonging to the set Q. In the example of figure 32, L\ and L3 belong to the set while L2 does 
not. 

Before we turn to illustrating the macro mechanism, let us make a remark on lexical specification 
in those computational architectures which express grammatical constraints on the level of a 
relational extension of the description language (group 2 architectures). So far, the discussion 
of the three possibilities for expressing generalizations over lexical entries were all based on an 
architecture like that of HPSG II, in which the domain of objects can be directly constrained 
(group 1 architectures) . Without using the technique for expressing group 1 theories in group 2 
architectures described in section 3.2.2, the first two possibilities for expressing generalizations 
discussed above are not available in a group 2 setup since the domain cannot be directly con- 
strained. One therefore only has the possibility to use the macro method, the syntactic grouping 
of descriptions under a name. This also is the case for the specification of lexical entries in those 
group 2 systems which use a phrase structure backbone. As a result, the phrase structure 
backbone based ALE and Troll implementation documented here makes heavy use of macros to 
specify the lexicon. 

To facilitate the presentation of examples from the implemented grammar, we now briefly in- 
troduce the macro mechanism of ALE. 43 Figure 33 shows a simple definition of a macro in the 
ALE implementation. 

unmarked macro (synsem: loc : cat : marking: unmarked) . 
Figure 33: Definition of macro "unmarked" 

A call to the macro, i.e. ©unmarked, is equivalent to writing [synsem|loc|CAT|marking unmarked] , 
i.e. the macro "unmarked" denotes sign objects whose marking values are of type unmarked. 

42 The reader thinking that "severely complicates" is an overstatement here, is reminded that encoding the 
relatively simple description of a word with a verbal head and [AUX plus] specification already demanded 19 
signature definitions (cf. figure 19 on p. 16). 

43 Note that, since macros are abbreviations for (ALE) descriptions, they cannot contain calls to definite clauses. 
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A macro can have parameters passed to it, allowing more versatile definitions. 



head(X) macro (synsem: loc : cat : head: X) . 
Figure 34: Definition of macro "head" 

Here a call, e.g. @head(verb) , abbreviates the description of a sign, whose head value has the 
value passed as the argument - the type verb. 

Other macros can be called in the definition of a macro. A restriction is that macro definitions 
are not allowed to be recursive. By using the call to a macro as a specification in the definition 
of another macro, hierarchies of definitions are formed. These hierarchies are subsumption 
hierarchies of descriptions. They have no theoretic status in the architecture of HPSG and 
should not be confused with type hierarchies as part of the signature. In the absence of other 
theoretically more satisfying possibilities (i.e. in the current implementation environments), such 
macro hierarchies are very useful for hierarchically grouping information. In the implemented 
grammar, the lexical entries were provided with the same information through such a hierarchy 
of lexical macros. It is displayed in figure 35. 




alldex 



adjjex 
wk-adjjex st-adj-lex 



substjex 



no_modJex 



njexl 
njex np-lex 



aux^lex main-V-lexl 
aux-flipjicLlex intransjex transjex ditransjex njindijjex 



Figure 35: The lexical macro hierarchy 

The macros become more specific the further down in the hierarchy one goes. Note that contrary 
to type hierarchies, where we know that every linguistic object has to be of a most specific type, 
any of the macros in the hierarchy can be used to specify a lexical entry, not just the most 
specific ones. 

Part of the information grouped in the lexical macro hierarchy above serves to specify theory in- 
dependent linguistic information (e.g. HEAD or CASE specification) and linguistic information 
driving a specific analysis (e.g. argument raising, NPCOMP value), other specifications seem 
to have a different status in supplying more general HPSG architecture mechanisms with infor- 
mation (e.g. NONLOCAL, QSTORE values). It seems obvious that this wealth of information 
and its dependence structure should find its way into a proper HPSG device - even though this 
section has illustrated that in most architectures (group 2 and those of group 1 which do not 
allow complex antecedents) it is not clear what such a device should look like. 

The macro hierarchies have often been confused with the lexical type hierarchies discussed 
on p. 26. Macro hierarchies define abbreviations for complex descriptions by hierarchically 
organized definitions of macros. The macros can then be used in the specification of constraints. 
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The confusion arises from the fact that the lexical types are introduced as encodings of complex 
descriptions (cf. p. 26). Nonetheless, lexical macro hierarchies and lexical type hierarchies are 
two completely different formal entities. The concepts and terminology from one can therefore 
not be carried over to the other without a redefinition. 

Summing up, there are three distinct approaches for expressing generalizations over lexical 
entries. It is possible to use several of these approaches in one grammar, but one should be 
aware that they employ different formal mechanisms to achieve their goal. 

4.1.3 Relating lexical entries 

Now that we have discussed basic lexical entries and the methods for expressing generalizations 
over them, we can turn to the second type of generalization used in HPSG-style theories: rela- 
tions specifying a lexical entry on the basis of another entry. Traditionally these relations are 
called lexical rules. Formally they are thought of as "meta-relations" , since they relate lexi- 
cal entries, i.e. descriptions and not the objects which are related by ordinary relations. Since 
a clear formalization of lexical rules as meta-relations has not yet been given, 4 we will only 
sketch under what idea of functionality linguists have used the lexical rule formalism in the 
formulation of linguistic theories. Following this introduction of the lexical rule mechanism, we 
will investigate how far we can get by expressing the generalizations captured in lexical rules 
as meta-relations strictly on the level of the description language. We then take a look at a 
computational mechanism which in the ALE system provides some of the functionality of lexical 
rules. As illustration of that computational mechanism, we show how the PVP extraction lexi- 
cal rule of HN can be encoded in ALE. The discussion of lexical rules ends with some remarks 
on the (non-)correspondence between linguistic and computational generalizations. Finally, as 
a possible theoretical and computational alternative to the lexical rules, an extension of the 
description language, the named disjunction mechanism, is introduced. 

Lexical rules 

In traditional terms, a lexical rule is a pair of two meta-descriptions, one for each class of 
descriptions related. Views vary significantly regarding the interpretation of the information on 
the two meta-descriptions and that of the lexical rule as such. 

Application criterion: 

Two different assumptions are made regarding the question of when a lexical rule applies to 
a lexical entry (a description): Either the lexical entry has to be more specific than the left- 
hand side of the lexical rule, or the lexical entry has to be consistent with the left-hand side 
of the lexical rule. Using the "more specific than" option is the more restrictive approach, 
which corresponds to the view of information in the lexical entry triggering the lexical rule. The 
"consistent with" option on the other hand additionally allows descriptions which are part of 
the left-hand side of a lexical rule to further narrow down the denotation of the lexical entry, 
which makes it impossible to distinguish between the specifications of the entry and that of the 
rule. 

Often the term subsumption is used for the "more specific than" relation and unifies with instead 
of "is consistent with". One should be aware that using these terms when talking about the 
lexical rule mechanism is very informal. Unification and subsumption are not even part of the 

44 Pollard (1993) is a sketch of such a formalization. 
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description language. It is therefore not possible to "lift" the two relations from the description 
language level to the meta description level. In fact, the issue of lexical rules as meta-descriptions 
is even more complicated, since even a formally defined "meta-subsumption" or "meta-unifies- 
with" would be inappropriate because entities on two different language levels need to be related. 
A lexical entry is a description whereas a lexical rule is a pair of meta-descriptions . The easiest 
solution would be to drop the idea of lexical rules as meta-relations and use ordinary relations on 
objects to capture the desired functionality. However, the following section will show that such 
an encoding misses some of the functionality associated with lexical rules. Before we analyze 
this matter further, let us finish the description of the functionality associated with lexical rules 
in intuitive terms. 

The nature of the transfer: 

Once the rule applies, the tags specified in the left-hand side "pick out" information from 
the lexical entry and "supply" it to the occurrences of the tags in the right-hand side. This 
information transfer can be done via "unification" or copying. 46 The specifications on the left- 
hand side of a lexical rule therefore has two functions: it triggers rule application and provides 
information handles. 

Unchanged specification carryover: 

Information "not changed" by the lexical rule is assumed to be transferred to the output. Several 
possibilities arise here concerning the interpretation of "not changed" and again the nature of 
the transfer. 

A formalization of lexical rules as meta-descriptions will have to refer to these choices. One 
should bear in mind that the exact formulation chosen has immediate consequences on the 
linguistic theories which can be formulated using the lexical rule mechanism. Hdhle (1994) 
shows that a lexical rule mechanism with unification as the application criterion does not work 
properly in a grammar where complement extraction is done via lexical rules and argument 
raising a la Hinrichs and Nakazawa is used to construct the verbal complex. 

Looking at the theory proposed in HN a further desideratum of the lexical rule mechanism 
presents itself. The PVP extraction lexical rule and the split-NP lexical rule share a common 
mechanism. Roughly speaking, partially extracted constituents are related to remnants in base 
position. This is implicit in the paper, but cannot be expressed in the formulation of the lexical 
rules. Using a hierarchically structured tool to relate lexical entries, it should be possible to 
express different levels of generalizations and capture the resemblance. To our knowledge, no 
formulation of such hierarchical lexical rules is proposed in the literature. 

Lexical rules as part of the description language 

In this section we investigate how far we can get by using only the description language to 
capture the functionality of lexical rules. Figure 36 shows a type definition for word, which 



In the Carpenter setup unification and subsumption play a role on the semantic level, not on the syntactic 
level of the description language. In the King setup, on which HPSGII can be based, unification and subsumption 
play no role at all. Cf. 2 

46 The tags which are often used to notate the information transfer in lexical rules as meta-descriptions should 
not be confused with the tags used in the description language. A description language tag is interpreted as 
identity of the set of objects denoted, whereas the lexical rule "meta-tags" specify identity of descriptions. 
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defines an extended lexicon including lexical rules. 



STORE < , , [OUT □] > ) 

lexjrule J ' 



word -> (Li V . . . V Li V . . . V L n V \T\ 

Figure 36: A lexicon with added lexical rule relations 



The formulation makes use of the junk slot technique discussed on p. 18 of section 3.2.1 for 
encoding relations on the level of the description language. The type word is assumed to have 
an additional appropriate attribute STORE which is list- valued. Furthermore a new type lexjrule 
is introduced below T, having IN and OUT as appropriate attributes with word values. The 
type definition for lex_rule, in which the different lexical rules are specified, is given in figure 37. 



lex-rule 



lexjrule 
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Figure 37: Specifying the lexical rules 



How does this description language encoding work? The definition of the lexicon in figure 36 is 
a type definition on the type word just like the basic lexicon of figure 30. Every object of type 
word has to satisfy one of the standard lexical entries L{ or it satisfies a special lexical entry |T| . 
The special entry [TJ is the description which is the OUT value of the lexicaLrule object residing 
in the special entry's junk slot attribute STORE. 48 

The admissible lex_rule objects are defined in figure 37. Because of the special lexical entry [7] 
in the type definition of word, every OUT description of a lexical rule object is a possible word. 
To relate the OUT value to another lexical entry, structure sharing between the descriptions 
Di and Ei of each disjunct in figure 37 needs to be specified. Note that the appropriateness 
conditions for lexjrule ensure that the value of the IN attribute is of type word. It therefore has 
to satisfy the type definition for word, i.e. one of the lexical entries of figure 36. Naturally that 
lexical entry can again be the output of a lexical rule. 

Let us illustrate the definition of a lexical rule, i.e. one of the disjuncts of figure 37, with an 
example based on the HPSG II appendix signature. For expository purpose only, assume we 
want to write a lexical rule, which extracts the subject of intransitive verbs with base verb-form 



Several equivalent formulations are possible. For example, two subtypes of word can be introduced, one for 
the standard lexicon (norrnaLword) and one for the results of lexical rules {lexjrule-word) . The type lexjrulejword 
has an appropriate, word typed IN attribute. The "out" specifications are specified directly on the lexjrulejuiord 
object. This encoding is basically the one used in the TFS grammars documented in Kuhn (1993) and Keller 
(1993). 

48 Note that the description of the special entry is a cyclic structure. This can be avoided if one instead 
introduces a lexjrule subtype of word as described in the previous footnote. However, the encoding with the cyclic 
structure has the advantage of clearly separating lexical rule objects from words. This makes it easier to compare 
the lexical rules in the description language setup with the other formalizations of lexical rule relations. 
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and inserts it on the inherited slash. The resulting encoding is shown in figure 38. 
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Figure 38: An example for a lexical rule description 



The description of the verb- form (tagged [T|) on the input ensures that only bse verbs can 
undergo this lexical rule. The tag [~x] references the (only) subcat list element of the input and 
is identified with an additional element of the slash set of the output description. The tags \T\ 
through \TT\ ensure that all other specifications are structure shared between the input and the 
output. 

What effect does this encoding have on the choices mentioned above for lexical rules as meta- 
relations: the application criterion, the nature of the transfer, and the carrying over of unchanged 
information? 

To make the following discussion easier to read, we call one of the disjuncts of figure 37, a 
description of admissible lex-rule objects, R. It's IN attribute bears the specification D and its 
OUT attribute the description E. Furthermore L is a lexical entry Lj of figure 36. 

When does the lexical rule R apply to a lexical entry L? The input specification D of the 
lexical rule R describes a set of word objects. Only those word objects which also satisfy the 
type definition for word satisfy our theory. Looking at that type definition in figure 36, this 
means that the word objects which are denoted by D also have to be in the denotation of a 
lexical entry L to satisfy the theory. The result is that a lexical rule applies to those objects 
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which are in the intersection of the denotation of the lexical entry L and the input description 
D. This semantic characterization on the syntactic side corresponds to the conjunction of the 
descriptions of D and L, which in the Troll setup is computed as the unification of the feature 
structure normal form representation of both descriptions. In the informal terminology of the 
lexical rule as meta-relation sketch above, the setup of lexical rules in figure 36 therefore entails 
that a lexical rule applies if its input description "unifies with" the description of a lexical entry. 

Now to the nature of the transfer. To state that two descriptions are partly identical, structure 
sharing (token identity) between parts of the descriptions of the IN attribute's value and that of 
the OUT attribute needs to be specified. Using the expressive power of the logic only, it is not 
possible to demand type identity without explicitly using the same description twice. The logic 
does not contain anything corresponding to the intuitive notion of copying. The result for our 
lexical-rule-like mechanism formulated within the description language is that the only way to 
relate the input and the output descriptions D and E is by specifying structure sharing between 
their sub-descriptions. 

Similarly, it is not possible to specify any "carrying over" of "unchanged" specifications. All 
"carrying over" is done by explicitly specifying structure sharing, i.e. all descriptions have to be 
explicitly specified on the OUT attribute. The grammar writer therefore has to decide for each 
lexical rule which information is to be preserved and ensure that it gets transferred from the 
input to the output of the rule. For two reasons it is sometimes very difficult to fulfill this task. 
Assume the following signature: 



T 




ti t 2 ai a 2 




_L 



Figure 39: An example signature 



Now take the description x ai and suppose we want to specify a second description so that 

it specifies all the information of the first, except that the value of its X attribute is specified as 
d2- This is only possible if we can access the type of an object independent of its attribute spec- 
ifications. No computational system currently provides this possibility. The type information 
t\ of the first description therefore can not be specified on the second feature structure without 
copying the whole t object including the [x a ± ] specification. The only solution is to split the 
lexical rule into many different lexical rules, one for each of the possible types of the objects 
which cannot be carried over completely. In the example above this results in two lexical rules: 
one for t\ objects and one for t 2 objects. In every more complex case this leads to a serious 
multiplication of lexical rules which loses some, possibly all originally intended generality. 

As a slightly more complex example based on the signature definitions given in the appendix of 
HPSG II suppose (for expository purpose only) we want to specify a lexical rule, which relates 
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all non-predicative entries to predicative ones. The only thing the lexical rule does is change the 
PRD attribute's value from minus to plus. All signs having a PRD attribute (i.e. the signs with 
substantive heads) can undergo this lexical rule. Regarding the question of which specifications 
of the input are supposed to be carried over to the output, the answer has to be that everything 
except for the HEAD value should be passed, since the HEAD value bears the PRD specification. 
The unintended but unavoidable result is that the type of the HEAD value object of the lexical 
entry (i.e. prep, noun, verb, or adj) is lost after the application of the lexical rule. The only 
solution is to split the original lexical rule into one for each HEAD subtype. These lexical rules 
then carry the specification of the HEAD subtype on the input and the output. Note that this 
completely loses the originally intended generalization over all non-predicative signs. 

The second problem regarding the specification transfer from input to output is caused by the 
fact that the feature geometry of lexical entries which can undergo a single lexical rule can 
vary significantly. In some cases the grammar writer therefore has to split up a lexical rule and 
specify which information gets carried over depending on the shape of the input. For example 
for the prd-lexical-rule of the last paragraph, a separate lexical rule would have to be made 
for verbs (to ensure the VFORM specification is carried over), nouns (to ensure the same for 
CASE), prepositions (PFORM), and for the only remaining substantial signs without specific 
head attributes, the adjectives. Again, the generalization over all substantial signs is lost. 

Summing up, it is possible to encode some of the functionality commonly associated with lexical 
rules on the level of the description language. However, the resulting description language 
mechanism commits the user to explicitly specify which information of the input is supposed to 
be present on the output. We have seen that this can cause problems. Nonetheless, the kind of 
description language mechanism defined currently is the only way to include at least the core of 
the functionality of lexical rules in a well-defined and formal way inside of the feature logic on 
which HPSGII is based. The restriction of the description language mechanism to an explicit 
transfer of specification is mainly caused by the problem to formalize the notion of a transfer of 
"unchanged specifications". We will see in the next section that the computational mechanism 
to encode lexical rules used in the ALE system has exactly the same deficits as our description 
language encoding. 

The PVP extraction lexical rule and its implementation in ALE 

Before turning to the specific ALE mechanism for lexical rules let us comment on the procedural 
metaphors commonly used with lexical rules. Even though lexical rules formally are binary 
relations without explicit order, one usually speaks of an "input" description and an "output" 
description of a lexical rule. The meaning of this is that the lexicon without the lexical rules is 
usually set up so that it contains certain lexical entries matching the input descriptions of the 
lexical rules, but none which match the output descriptions. When the procedural metaphor 
behind this terminology is transferred into a procedural interpretation in the sense that lexical 
rules produce new lexical entries (like in the ALE system), this can lead to unintended results. 
The problem is that different application orders can produce several instances of the identical 
lexical entry. 

Take for example two lexical rules R\ and R2 which both apply to a lexical entry A. Additionally 
assume R\ and R2 modify different parts of A and that the intersection of the denotation of the 
output description of either of the rules and that of the input description of the other rule is not 
empty. In this situation, a procedural interpretation of lexical rule application would produce 
four new entries, one resulting from the application of R\, one from the application of R2, one 
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from applying i?i and then R2, and finally one where first R2 and then R\ was applied. The 
last two possibilities cause two identical lexical entries to be added to the lexicon. Clearly such 
a production of identical entries is an unwanted effect of the procedural interpretation of lexical 
rules. 

In the ALE system, lexical rules are basically a special notation for unary phrase structure rules 
with an additional mechanism to alter the morphology. When the grammar is compiled, the 
closure under lexical rule application is computed. New lexical entries are produced and added 
to the lexicon. As mentioned above this can lead to identical entries as the result of several 
possible orders of application of one lexical rule on the output of another. Application is done 
with unification as test, and the new entry is created with copies of the information specified in 
the tags. Just as with the description language formalization just discussed, only the information 
explicitly specified on the right-hand side of the lexical rule finds its way into the new entry. The 
resulting problems noted above therefore apply to the ALE formalism as well. 49 An additional 
complication of the specification transfer issue can arise from the procedural interpretation of 
the lexical rules. Because of different possible application orders, an insufficient specification of 
propagation of information from input to output can lead to unwanted unilateral subsumption 
between entries (in addition to identical entries resulting from applying the same lexical rules in 
different order). Whether all unilateral subsumption can be eliminated by changes to the lexical 
rules depends on the possibility to completely pass unchanged information. As discussed above 
this can sometimes only be achieved at the loss of generality by splitting a lexical rule into many 
different lexical rules. 50 

To illustrate a lexical rule encoding in the ALE system, let us take a closer look at the PVP 
extraction lexical rule which in HN drives the analysis of possibly partial verb phrase extraction. 



In the implemented grammar it was possible to avoid the problem regarding the different feature geometries 
of input and output lexical entries because of the homogeneous nature of the application domain of the lexical 
rules in the fragment (mostly verbal entries). 

50 In the implementation, extra PROLOG routines were used to detect and eliminate mutually and unilaterally 
subsuming lexical entries. With additional specifications on the lexical rules and entries it was possible to eliminate 
the unwanted lexical entries in the special case of the implemented grammar. 



36 



W. DETMAR MEURERS 



Figure 40 shows the lexical rule as given in HN 51 . 
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Figure 40: The PVP extraction lexical rule 



Figure 41 shows the corresponding ALE encoding: 

pvpelr lex_rule 

(In, ©verb, @bse, 

@plus_aux, 
@val_comps ( [ (©verb, @vf orm(Vf orm) , 
@val_comps (Comps) , 
@val_subj (Subj ) , 
@cont(Cont)) 
I Comps ] ) , 
@no_in_slash) 



**> 



(Out, @val_comps( (L, list_n_sign) ), 

@in_slash([ (Overb, @vf orm(Vf orm) , 
@comps_sat , 
@val_subj (Subj ) , 
@cont (Cont) , 
@in_slash(L)) ])) 



if 



pass2(In,0ut) 
morphs 

X becomes X. 



The ordering on the comps list is inverted compared to the figure given in HN. Cf. section 5.1 for a discussion 
of this issue. Also, the [VFORM bse] specification on the input is only implicit in the formulation of the PVP 
extraction lexical rule given in figure 19 of HN. 
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Figure 41: The encoding of the PVP extraction lexical rule 

Due to the systematic use of macros, the implementation encoding closely resembles the lexical 
rule given in HN. The only difference concerns the value of the COMPS attribute in the output 
description. Since ALE does not support polymorphic types or negation of descriptions, the "list 
of non-verbal signs" -description on the COMPS attribute cannot be expressed directly. In the 
current theory, restricting the COMPS value of the output of the PVP extraction lexical rule 
to be a list of nominal signs, will also makes the intended correct predictions. 52 The negated 
descriptions therefore can be replaced with the description of a list of nominal signs. Due to the 
absence of polymorphic types, the method for encoding descriptions in the signature definition 
of a type (cf. section 3.2.1, pp. 15) was used to introduce a new type list-nsign for "list of signs 
with a nominal head" . This type constraint was then used to restrict the value of the COMPS 
attribute in the output of the lexical rule in figure 41. 

The call to the definite clause pass2 at the end of the lexical rule encoding of figure 41 takes 
care of the carrying over of information not changed by the lexical rule. The definition of the 
definite clause and the macro involved in passing all but the changed COMPS and INHERITED 
information is given in figure 42. 

pass2 (@core2 (Qstore , Retr , Head , Marking , Npcomp , Val_sub j , Val_spr , Cont , Conx , To_bind) , 
@core2 (Qstore , Retr , Head , Marking , Npcomp , Val_sub j , Val_spr , Cont , Conx , To_bind) ) 
if true . 

core2 (Qstore , Retr , Head , Marking , Npcomp , Val_sub j , Val_spr , Cont , Conx , To_bind) macro 
(word, (qstore: Qstore), 
(retr : Retr) , 
@head(Head) , 
©marking (Marking) , 
©npcomp (Npcomp) , 
@val_subj (Val_subj) , 
@val_spr (Val_spr) , 
@cont (Cont) , 
Oconx(Conx) , 
@to_bind(To_bind)) . 

Figure 42: The mechanism for passing the unchanged specifications (everything but comps and 

inherited slash) 

The parameter list of the macro core2 is used as an interface to all relevant attribute specifica- 
tions. In the definite clause pass2 the macro core2 is called twice, once for the input and once 
for the output. For both calls the same variables are passed as arguments, ensuring identity 
between the relevant attribute specifications of input and output. 

52 The same reasoning holds for the constraint on the elements which can undergo argument raising on the 
comps list of auxiliary verbs. Just as in the PVP extraction lexical rule case, the grammar implemented restricts 
them to be nominal signs. 
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Besides the PVP lexical rule driving the analysis of partial VP topicalization, several others 
lexical rules were included in the implementation to obtain a simple and consistent grammar: A 
morphological rule relating the negative indefinite "kein" to the various forms of "ein"; several 
morphological rules with syntactic effect obtaining finite, past participle, and substitute infinitive 
forms of verbs; syntactic rules introducing unbounded dependencies in lexicalized style for com- 
plement and subject extraction; and finally a rule freeing the complement order of ditransitive 
verbs. 

Linguistic generalizations and computational compactness 

In the last sections we have been concerned with mechanisms for expressing generalizations over 
the lexicon by relating lexical entries. We sketched the functionality desired by the linguists, 
showed that a formal mechanism inside of the logical setup of HPSGII does not capture all of 
these desiderata, and displayed the computational mechanism used in ALE which is equivalent 
to the description language mechanism regarding the functionality captured. The discussion so 
far was focussed on how the linguistic generalization are expressed, i.e. on the functionality of 
the mechanism. 

Regarding computational mechanisms for expressing lexical rules, an issue besides the function- 
ality offered deserves some discussion. From the computational point of view it is important 
whether the methods used to express the linguistic generalizations have correspondents on the 
computational side. In other words, in an ideal computational setup, the methods used to 
express linguistic generalizations should have a counterpart in a compact and elegant computa- 
tional encoding which can be dealt with using efficient algorithms. We have seen that in the ALE 
system there is no such correspondence. The lexical rules are only used to produce new lexical 
entries for a bigger lexicon, which is then used in processing. This is particularly inelegant since 
the new entries produced usually only differ in very few specifications, namely those altered by 
the lexical rules. 

There seem to be two possibilities to improve on this situation. One could use the ALE mech- 
anism with an alternative processing strategy. It would supply new lexical entries whenever 
a lexical entry is needed in the local tree being processed. 53 However, such a straightforward 
application of lexical rules "on the fly" is very inefficient since every time something needs to be 
licensed by a lexical entry all lexical rules have to be applied in all possible orders to collect all 
possibly matching entries. A more complicated scheme could use some kind of tabelling method 
to keep track of the lexical entries already produced. But since it is completely unconstrained 
which specifications can be changed by a lexical rule, in the general case such a tabelling method 
will result in compiling out the lexicon upon the first lexical lookup to make sure that all pos- 
sible solutions are found. Naturally this is even less desirable than compiling out the lexicon 
beforehand. 

The other possibility uses the insight that the lexical entries resulting from lexical rule application 
usually only differ in very few specifications compared to the number of specifications in the 
lexical entry as a whole. Instead of expressing relations between lexical entries - which in a 
formal mechanism causes significant problems regarding the transfer of unchanged specifications 
from input to output - one can use a single lexical entry and encode the possible variations in 
that entry. Note that the variations cannot be captured with simple disjunctions since the value 
of one specification might depend on the value of another. Let us therefore call them systematic 



The same effect follows from using the description language mechanism introduced above in a group 1 setup. 
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covariations. 

Using relations to encode systematic covariation in lexical entries 

The question we are interested in is how the lexical rules proposed by the linguists can be (auto- 
matically) translated into a system of relational dependencies introducing systematic covariation 
within lexical entries. A full discussion of this topic is beyond the scope of this paper. We will 
therefore only sketch an approach using the relational extension of the description language. As 
an alternative, we will briefly introduce an extension of the description language with so called 
"named disjunctions" in the next section. 

The lexical rules and the mechanism for introducing systematic covariation are intended to 
capture the same generalizations. Still, they are very different in the way they work: The 
systematic covariation encoded as relational dependencies in the lexical entries capture the 
difference between a "basic" lexical entry and all those lexical entries which are the result of 
(successively) applying the lexical rules to that basic entry. Or in more computational terms: 
in the covariation approach, calls to definite clauses are attached to lexical entries. The definite 
clauses introduce disjunctive specifications in a lexical entry. 

Lexical rules on the other hand relate lexical entries. Compared to the covariation setup they 
lift the relational dependencies from within a lexical entry up to the level of the lexical entries. 
This allows us to generalize over whole classes of lexical entries. These kind of generalizations 
over classes of lexical entries seem to be lost in the covariation approach, since the covariation 
is encoded inside of each lexical entry. This is not true though if we can use a call to the same 
relation in all or a natural class of lexical entries to introduce the intended covariation. To be 
able to define such a relation, we need to know which lexical rules can apply in what order on 
which lexical entries. This information can be retrieved from the input and output specification 
of the lexical rules. By checking which input of a lexical rule is compatible with which output, 
we can obtain a graph representation of all possible application orders of lexical rules to an 
entry. Figure 43 is such a graph for the lexical rules which in the implemented grammar apply 
to the class of verbal entries. 



Figure 43: The lexical rules applying to verbal elements and their interdependence 

Each edge corresponds to the application of a lexical rule 54 . Each node relates to one solution 
of a definite clause attached to a lexical rule. The specifications in curly brackets describe the 



The abbreviated lexical rule names have the following expansions: subject extraction (SELR), partial vp 
extraction (PVPELR), finitivization (bse_to_3_sing, bse_to_3_plur) , finitivization (finit.), and past participle for- 
mation (bse_to_psp, bse_to_subst_bse) . The celr + is the complement extraction lexical rule modified in such a way 
that it allows the extraction of any number of complements greater than 0. It for example only has to be applied 
once to extract both objects of a ditransitive verb. The e stands for no change. 
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set of lexical entries for which the graph as a whole or a certain edge is applicable. 

The graph displayed applies to verbal entries with bse verb-form, which in fact are the only verbal 
entries specified in the basic lexicon of the fragment. The PVPELR only apply to auxiliary verbs 
and the CELR only to full verbs. The restrictions which are already ensured by the specification 
of the output of a lexical rule do not need to be listed separately. For example the SELR only 
applies to finite verbs. Since the finitivization rules leading to node 5 ensure that their result is 
finite, no additional specifications are necessary. 

For the issue we are pursuing, the graph can be used as backbone for an encoding of the lexical 
rule regularities in the relations called in the lexical entries. Such a backbone is constructed by 
encoding the graph as finite state automaton in one definite clause which is attached to every 
lexical entry. Every node is a solution, i.e. a possible lexical entry, and every label of an arc is 
a call to a relation encoding the variation introduced by the corresponding lexical rule. 

In one of the Troll versions of the grammar Guido Minnen and I encoded lexical rules in the 
way described. This drastically reduced the number of lexical entries compared to the original 
compiled out ALE lexicon. The result is a lexicon which captures at least some of the linguistic 
generalizations behind the lexical rules in a computationally usable way. 

An alternative mechanism: named disjunction 

Before we leave the area of generalizations over lexical information, let us briefly introduce an 
alternative mechanism using an extension of the description language for expressing systematic 
covariation in lexical entries: named disjunctions of complex descriptions used in the specification 
of lexical entries. 

To illustrate this mechanism we will look at an example from the interaction of morphology and 
syntax. In HN (adapting a proposal from Pollard (1990)) base verbs differ from finite verbs in 
three respects. The subject of a finite verb is encoded together with its complements, whereas 
that of a base entry is specified in the separate attribute SUBJ. Nominative case as well as 
number and person information is specified for the subject of finite verbs, but not for that of 
base ones. Finally the verb form is encoded in the attribute VFORM. A fully expanded lexicon 
would contain seven unrelated entries and the relation between these would be lost. Note also 
that the described complex interaction of morphological and syntactic features of finitivization 
cannot be encoded using simple disjunctions, since the case and agreement assignment, as well as 
the valence encoding depends on the verb form. Figure 44 shows the resulting named disjunction 
encoding. 



Figure 44: A named disjunction expressing finitivization a la Pollard (1990) (cat value shown) 



VAL 



HEAD 




nom 



cat 



The notation needs some explanation. The -^F abbreviates the path starting with SYNSEM 
down to the attribute F. The angle brackets are used as list notation, to distinguish them from the 
square brackets of the AVMs. Named disjunctions are noted as { nam e disji ; disji ; . . . ; disj n } 
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A named disjunctions is interpreted in the following way: In every disjunction with the same 
name, the disjunct in the same position has to be chosen. 

In the figure 44 the named disjunction v encodes the described dependence. If the first disjunct 
of the named disjunction v is chosen, the finite verb-form is selected, the SUBJ attribute is 
assigned the empty list, and the subject as first element on the COMPS list receives nominative 
case. In case the second disjunct is chosen, the VFORM is bse, the SUBJ attribute contains the 
singleton list with the subject as element, and only the complements are encoded in COMPS. 
The subject and the complements of the finite and the non- finite choice are related, since the 
SUBCAT list is outside of the disjunction. 

If the specification in figure 44 is included in the grammar as constraint on signs with verbal 
head value, an example lexical entry for a verb can be specified as in figure 45. 



word 



PHON { w { n {p liebe ; liebst ; liebt} ; {p lieben ; liebt ; lieben} } ; lieben} 

~>VFORM { w fin ; bse} 

NUM { n sg ; pi} 
PER {p 1st ; 2nd ; 3rd} 



SUBCAT < 
-^CONT 



AND \T\ A 



[~>IND |T|] 



love 



LOVER 
LOVED 



Figure 45: An example entry for "love" 



The lexical entry specifies the semantics and identifies the thematic roles with the syntactic 
indices in the standard fashion. Additionally the named disjunction mechanism takes care of 
two things. The disjunction w takes care of the choice between finite and base phonologies by 
relating the phonology value to the value of VFORM. In the case of a finite verb there is an 
additional choice regarding the agreement between the index of the subject and the phonology 
of the verb. The named disjunction n mediates the choice between singular and plural, and p 
links the person specification on the index to the correct phonology. If instead we are dealing 
with a base verb, the named disjunctions n and p only occur once, namely in the specification 
of the subject index, since the second disjunct of w is chosen. Such a single occurrence of a 
named disjunction is equivalent to a single disjunction. The index of the subject can therefore 
have any of the values noted. 

The encoding using named disjunctions bears a close resemblance to encodings on the relational 
level discussed above, e.g. in the form of definite clause attachments to lexical entries. Nonethe- 
less, there is a difference worth noting: The named disjunction mechanism is weaker than the 
definite clause mechanism in that it does not allow recursive definitions. Only simple covariation 
can be expressed, which is exactly what is needed for the desired encoding. 

Summing up, the advantages of the named disjunction mechanism are its declarative semantics, 
its restricted expressive power corresponding to the needs, and the resulting compact encoding of 
linguistic generalizations in a computationally usable way. Which class of lexical generalizations 
can be captured in this way, should therefore be interesting to investigate. 55 For a detailed 



55 The reader interested in constraints on named disjunctions as models for lexical rules should note that the 
example given crucially depends on two things. To relate the information of one disjunct of a named disjunction 
to another disjunct of a disjunction with the same name, the disjuncts have to structure share with an object 
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investigation and formal definition of named disjunctions, the reader is referred to Eisele and 
Ddrre (1990) and Griffith (ming). 

Concerning the computational systems, it remains to be mentioned that Troll currently only 
supports named disjunction of types, while ALE does not support them at all. 

4.2 Structure licensing 

In HPSG, constituent structure is licensed via immediate dominance schemata and linear prece- 
dence rules. Using a pure constraint logic programming approach to computation, this mech- 
anism can be directly encoded. Such an approach, however, leaves us with two problems: one 
regarding the control structure to be applied in constraint resolution - since the special guiding 
status once attributed to fixed information on phrase structure is now lost in a vast pool of 
non-distinguishable constraints; the other in licensing linear order with LP statements which 
makes strong demands regarding the expressive power of the constraint language. 56 

The alternative, traditional approach to structure licensing uses the information about the num- 
ber of daughters of a certain construction - and optionally other information specified on con- 
stituents together with the required word order - and encodes it in phrase structure rules. 
Generalizations over that information are lost. 57 The obtained phrase structure backbone can 
then be used to drive highly specialized efficient algorithms to license structures. Finally, to 
express some general constraints on rules, definite clauses can be attached to them. In a phrase 
structure backbone architecture with definite clause attachments, the number of daughters is the 
only information which - compared to an ID/LP approach - has to be additionally specified. 58 
All the specifications on constituents distinguishing one constituent from the other and thereby 
specifying a certain ordering as well, can theoretically be included in the definite clause attach- 
ments. Nonetheless parsing algorithms are more efficient, the more information is present on 
the constituents. 

While the traditional approach has the clear disadvantage of differing from the ID/LP format 
used in HPSG theory, it nevertheless leaves the implementer using the current parser based 
systems 59 with an interesting choice regarding generalization vs. performance: generalizations 
over rules can be captured by encoding the information in a definite clause which is attached 
to all the rules generalized over. The performance drawback of this encoding is that - since (in 
general) definite clauses are executed after a construction has been accepted by the parser - they 
do not contribute to the information available to the parsing algorithm. 60 This is a disadvantage 
for processing, since as mentioned the phrase structure backbone approach is faster the more 

outside of the disjunction. In the example this is done via the SUBCAT list, which contains the subject of both 
finite and non-finite verbs. The second point to mention concerns the disjunction names. These names only make 
sense local to a description. Since the example is based on a constraint applying to signs with verbal heads and a 
description representing the lexical entry, the choice of the verb-form has to be repeated in the lexical entry itself 
in order to mediate the choice between the constraint and the lexical entry. 
56 Cf. Meurers and Morawietz (1993) for a discussion of the LP formalism. 

57 For an approach introducing some word order generalizations into a phrase structure grammar, the reader is 
referred to the SUP formalism introduced in Meurers and Morawietz (1993). 

58 The operator "cats>" supplied by ALE allows to specify a list of daughters, which at compile time do not 
have to be of fixed length. Nonetheless it does enforce the number of daughters to be fixed at run time. 

59 In principle, parsers can be extended to ID/LP rules and possibly to ID/LP schemata as well. Cf. Shieber 
(1984), Seiffert (1991), and Morawietz (1994). 

60 Note that partial execution of definite clauses at compile time can make further information available for the 
parser. 



ON IMPLEMENTING AN HPSG THEORY 



43 



information is specified per constituent in a rule, while the exact algorithm used determines the 
constituent (e.g. leftmost constituent) on which information specification has the most effect. 



4.2.1 An example for phrase structure rules with the feel of ID schemata 



In the following, one solution to the generalization vs. performance choice is presented using 
an example from the implementation of HN. The general idea is to use macros and a definite 
clause to express the generalizations over the group of PS rules which replace one ID schema. 
Regarding terminology, we will speak of the macro and definite clause as the core of a group of 
PS rules which encode one ID schema. 

Generalizations over PS rules are captured in two ways: On the one hand, the specifications valid 
for all constituents of a certain function (e.g. head, complement, or mother) are collected in a 
macro which is used in all occurrences of a daughter of that function in every rule of a group. The 
specifications specific to a rule are captured via parameters passed to the macro or by conjoining 
the specific descriptions to the call of the macro. On the other hand, generalizations over 
constraints on the whole tree (like the grammatical principles discussed in the next section) are 
expressed in a definite clause which is attached to all PS rules of one group. These two methods 
for the specification of phrase structure rules conserve at least some of the generalizations and 
intuitions behind the original ID schemata of the linguistic theory. 

To illustrate how the ID/LP constraints of HN were encoded as PS rules using the method 
described, let us take a look at the head- complement ID schema. 61 This ID schema licenses 
constructions with up to five daughters and a highly varied word order depending on the spec- 
ification of the head (e.g. AUX and INV specification on verbal heads) which - as follows from 
the discussion above - leads to a high number of phrase structure rules. 62 The head-complement 



In HN verbal projections are licensed by the verbal-complex and the head- complement schemata. Because 
of the valence encoding issue discussed in section 5.1, the implementation additionally distinguishes a group of 
head-subject-complement rules for finite sentences from the head- complement group of PS rules, which in the 
implementation only licenses non-finite VPs and finite sentences with extracted subjects. 

62 While a high number of rules naturally slows down performance, some performance can be regained, since 
some of the rules become so specific that it is known which class of lexical heads are possible in which rule. 
Therefore more information can be specified in the rule, speeding up the system. It should be clear though that 
this additional specification of information already encoded in the lexical entries is a theoretically unmotivated 
repetition. Trying to lose this redundancy by only specifying the information in the rules, conflicts with the 
increasing lexicalization going on in linguistics today. Phrase structure based formalizations therefore seem 
to be inappropriate for modern lexicalized theories. Still, future pre-compilation techniques might be able to 
automatically add additional specifications to phrase structure rules, which can be deduced from interaction with 
the specification of the lexicon used. 
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ID schema of HN is shown in figure 46. 



SYNSEM|LOC|CAT 



Figure 46: The head-complement ID schema of HN 

In the implementation the specifications of the mother and the head category of this ID schema 
are captured in the following core definitions, which apply to all PS rules of the head-complement 
group. 

hc_mother (S) macro (©verb, 

@comps_sat , 

@plus_npcomp, 

@val_subj (S) , @spr_sat) . 

hc_head(S,C) macro (@no_to_slash, 

@val_subj (S) , @spr_sat, @val_comps (C) ) . 

Figure 47: The macro core of the head-comp group 

Before going through the specifications, a short note on the notation used might be appreciated. 64 
Variable names, serving the same function as the structure sharing tags in HPSG, are noted 
with a capitalized first letter. Names following an "@" character are calls to macros, and will be 
replaced at compile time by the complex description which the macro abbreviates. The type of 
the description abbreviated is noted in the name of the macro. Macros with a suffix "_y" are of 
type synsem, those without suffix (all the macros in figure 47) of type sign. Finally, the commas 
within the parenthesis are interpreted as conjunction (except when separating the arguments of 
a macro), and the square brackets represent the normal list notation of PROLOG. 

Comparing the core definitions of the implementation with the original formulation of the Head- 
Complement ID schema we note a close similarity: The macro hc_mother, which specifies all 
the information on the mother of each PS rule of the head-complement group, contains the 
specifications present on the mother of the ID schema in figure 46. In addition - for reasons 
discussed below - all valence information is included, which accounts for the extra @val_subj 
and @spr_sat. The same holds for the head: like the head in the ID-schema, the macro hcJiead 
contains a TO-BIND specification. In addition the valence information is accessed. The specifi- 
cation of the one optional verbal and the more than one nominal complements in figure 46 cannot 

63 Because the head- complement ID schema of HN depicted in figure 46 (= figure 21 of HN) demands the 
occurrence of at least one non-verbal complement, HN also call it Head-NP-Complement ID. 

64 The macro mechanism of ALE was introduced in section 4.1.2 on pp. 26. For a full definition of the ALE 
syntax, the reader is referred to Carpenter (1993). A set of comments on the additional conventions used in our 
grammar can be found in section 5.4.2. 



HEAD verb 
COMPS () 
NPCOMP plus 



H [NONLOC|TO-BIND|SLASH ()] , 

C [SYNSEM |LOC| CAT I HEAD -iverb] + . 

(C [sYNSEM|LOC|CAT|HEAD verb]). 
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be elegantly expressed in a macro for the complement function. The number of complements 
is not fixed in the schema. Still certain properties of possibly occurring complements need to 
be specified, which makes it necessary to fix a certain order of complements. The complements 
therefore need to be specified separately in each PS rule of the head-complement group. 

Figure 48 shows one PS rule of the head-comp group which makes use of the macro core. First, 
some comments on the ALE notation used: The operator ===> separates the mother of a phrase 
structure rule from the daughters. Each daughter is prefixed with cat> and ends with a comma. 
Finally, the goal> operator allows us to add calls to definite clause relations to the phrase 
structure rule defined. The phrase structure rule can only be used to license a local tree, for 
which the relational constraints attached to the rule are satisfiable. 
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hc_minus_inv2 rule 

(Mother, @hc_mother (S) ) ===> 
cat> (C2, @obj_np), 
cat> (CI, @obj_np), 

cat> (Head, @hc_head(S, [C1,C2] ) , @n_fin, @minus_inv) , 
goal> hc_goal(hcni2, Mother, Head, [C1,C2]). 

Figure 48: Phrase structure rule of the head-comp group 

This rule licenses non-inverted non-finite VP constructions in which a verbal element combines 
with two complements. For the mother category of the construction, only the information valid 
for the whole HC group (the core specification defined in figure 47) is specified via the call to the 
macro @hc_mother. The variable Mother is conjoined to that specification to feed the definite 
clause hc_goal discussed below. Similarly, the macro ShcJiead is called as description of the 
head, and the variable Head is conjoined to the whole specification to be used in the call to 
the definite clause. Two more things should be mentioned. For reasons that will be explained 
in the next section, the valence principle is compiled into each rule. The argument list of the 
mother macro (S) and that of the head macro ( [S] , [C1,C2]) serve to mediate the valence 
information. The conjuncts @n_f in and @minus_inv in the description of the head daughter 
specify that only non-finite non-inverted heads can appear in this rule. This is not included in 
the general OhcJiead specification, since the HC-ID also licenses inverted or finite constructions. 
The specification of the complement daughters as nominal complements results from two sources. 
The HN specification of the head-complement ID schema of figure 46 demands there to be at 
least one non-verbal complement and an inspection of the lexical elements which can appear as 
heads in this rule tells us that both complements have to be object noun-phrases (@obj_np). 65 
At the bottom of the rule, the goal expressing the constraints applying to all HC constructions 
(@hc_goal) is called and the rule specific specifications (the name of the rule for identification 
in the parse tree, the mother, the head, the subject and the list of complements) are passed 
as arguments. The definition of the definite-clause core for the head-comp group is shown in 
figure 49. 

hc_goal (Subtype, Mother, Head, Comps) if 

dtrs(Mother, @head_comp_cs (Subtype , Head, Comps)), 
principles (Mother, Head, Head, [Head | Comps] , Head). 

Figure 49: The definite-clause core of the head-comp group 

The call to the dtrs relation serves to build up a parse tree. It is included in the definite clause 
core and not in the PS rules in order to separate it as much as possible from the linguistically 
motivated specifications. The call to the principles on the other hand serves as universal attach- 
ment of the grammatical principles. All information necessary for the principles is supplied via 

65 This is a good example for the additional specifications in phrase structure rules mentioned in footnote 62. 
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the five arguments. This allows us to use exactly the same principles relation for all PS rules. 
We will see in the next section how the principles are encoded in this relation. 

Finishing up the issue of encoding dominance relations, it remains to be mentioned that in the 
grammar the head-complement schema, the verbal-complex schema, and the extra head-subject- 
complement schema are encoded using the mechanism just described. For each of the other ID 
schemata in the fragment (marker-head, specifier-head, adjunct-head and filler-head) there is 
a one to one correspondence between PS rules and ID schemata, since they introduce a fixed 
number of daughters. 

4.3 Expressing the principles 

In the last section we saw two options for specifying constraints on a construction: directly 
encoding the constraints in a rule ensuring maximal performance, and the usage of definite 
clauses yielding maximal generality. When deciding how to encode the principles of a grammar 
(e.g. the head feature principle or the semantics principle of HPSG II) we are again faced with 
those two possibilities. 66 

Due to the decision to stay as close to the linguistic theory as possible, the head feature principle 
(HFP), the nonlocal feature principle (NFP), the semantics principle (SemP), and the marking 
principle (MarkP) were each encoded in a separate definite clause and then conjoined in a 
clause "principles" which then was attached to all groups of PS rules. Regarding processing, 
not specifying these principles in the phrase structure backbone has only a small negative effect, 
since these principles mostly relate information in the mother to information in the daughters, as 
opposed to expressing relations between the daughters. Since most of the information originates 
in the lexicon, the bottom-up strategy employed by the systems used would only marginally 
profit from the information mediated by those principles. The interface between a rule and 
the principles consists of five arguments: Mother, Syntactic_Head, Semantic_Head, List_of_Dtrs, 
and Marking_Dtr 67 . This encoding allows an elegant general encoding of the principles, without 
having to specify choice procedures (e.g. picking out the semantic head) depending on the type of 
the construction. Figure 50 shows the definition of the principles in the implemented grammar. 

principles (Mother, Head, Sem_head, Dtr_list, Marking_dtr) if 
(hfp (Mother, Head) , 
nfp(Mother, Head, Dtr_list) , 
sem_p(Mother , Sem_head, Dtr_list) , 
marking_p (Mother ,Marking_dtr) ) . 

Figure 50: Definition of the definite clause principles 

66 I here only note the possibilities in a phrase structure backbone based system. As discussed in the section 3.2 
on expressing constraints, the principles in HPSG II are expressed as implicative constraints just like the rest 
of the grammar. In a general group 1 constraint resolution system one has the choice to directly encode the 
principles as object definitions a la HPSG II or to compile the principles into the object definitions expressing the 
immediate dominance schemata. Choice here is influenced by the strength of constraints that can be expressed in 
the language used (e.g. if complex antecedents are available) and the question of when which kind of constraint 
is resolved (compile or runtime). 

67 The Marking_Dtr is the marker of a headjnarker construction and the head in any other construction. 
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The head feature principle (HFP) is encoded as displayed in figure 51. 

hfp(@head(X) ,@head(X)) if true. 

Figure 51: Definition of the definite clause hfp 

When we compare this definition with the HFP as given in HPSGII (which, for the sake of 
convenience, is repeated below), we note that only the consequent of the implication is expressed 
in the definite clause. The antecedent is implicit in the encoding, since the definite clause 
principles is only attached to PS rules licensing phrases dominating headed structures. 68 



phrase 



DTRS headed- struc 



SYNSEM|LOC|CAT|HEAD 

DTRS | HEAD-DTR| S YNSEM | LOC | CAT | HEAD 



Figure 52: The HFP 



Note that the HFP encoding does not actually make use of the expressive power of the definite 
clause mechanism. Were we not interested in capturing generalizations as discussed above, the 
HFP could be encoded directly in the PS rules. This is different for the nonlocal feature principle 
(NFP) shown in 53. 

nfp(@in_slash(Diff ) , @to_slash(Head_To_slash) , Dtr_list) if 
(collect_in_slash(Dtr_list , In_slash) , 
list_dif f (In_slash,Head_To_slash,Dif f ) ) . 

Figure 53: Definition of the definite clause nfp 

Again the definition from the appendix of HPSGII is included below. Since in the fragment 
we are only concerned with the nonlocal feature SLASH, the references to the other nonlocal 
features QUE and REL are omitted. 



In a phrase whose DAUGHTERS value is of sort headed- structure, the value of 
S YNSEM | NONLOCAL | INHERITED | SLASH is the set difference of the union of 
the values on all the daughters and the value of SYNSEM|NONLOCAL|TO- 
BIND| SLASH on the HEAD-DAUGHTER. 

Figure 54: The NFP for the nonlocal feature SLASH 



Note that this time it is not easily possible to rewrite this text definition as an AVM. The 
"union of the values on all the daughters" cannot be directly expressed, since each subtype of 

68 The fragment does not contain any non-headed structures. Therefore the definite clause principles can be 
attached to all PS rules. 
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constituent- structure has different attributes in which the daughters of a construction are stored. 
In the implementation, the list of all daughters therefore is one of the arguments passed to the 
principles, which enables us to use a uniform, recursively defined relation collect _in_slash to 
collect the INHERITED | SLASH values of all daughters. Note that - for reasons explained in 
section 5.2 - in the implementation SLASH has a list instead of a set value. The "set difference" 
of the original definition therefore becomes the list_dif f relation in figure 53. Without going 
into the definitions of the two predicates doing the collecting and the calculation of the difference, 
it should be clear that specifying these operations on lists of undetermined length requires the 
extra expressive power of the definite clause mechanism. As a last comment on the encoding of 
the NFP note that the call to the macros @in_slash and @to_slash in the first two arguments 
of nfp serve to select the INHERITED | SLASH value of the mother sign, which is passed as the 
first argument, and the TO-BIND| SLASH of the head sign, which is passed as the second. 

The valence principle (VP) does not fit well into the schema used for encoding the principles 
as definite clause attachments on PS rules. As mentioned above, the HFP, NFP, SemP, and 
MarkP mainly relate information between the mother and the daughters. The VP additionally 
relates information between the head and the other daughters. Since this is valuable information 
for any processing regime, it is encoded separately in each group of rules without the usage of 
definite clauses. Additional motivation for this dividing up of the valence principle comes from 
the fact that it does not easily lend itself to a general formalization. The formulation in HPSG II 
uses variables over attributes and attribute name manipulation (e.g. to obtain SUBJ-DTR from 
SUB J) both of which are neither part of the logic behind HPSG II as provided by King (1989) 
or Carpenter (1992) nor of ALE or Troll. Encoding the function of a sign in the value of an 
attribute of the sign - as proposed in Meurers and Morawietz (1993) or realized in Meurers (1993) 
- enables the grammar writer to refer to the function. All subcategorization requirements can 
then be encoded in a single attribute and all daughters of a local tree in a single list valued 
daughter attribute of constituent structure without losing the distinction between the different 
functions. 69 



5 Relating the specific linguistic theory to its implementation 

This section illustrates some issues concerning the specific linguistic theory of HN which arose 
in writing the grammar. It explains where the implementation differs from the original theory. 70 



5.1 Encoding valence 

In the discussion on German sentence structure about the existence of a verb phrase in German, 
Pollard (1990) proposes that German lacks a finite vp while it does have a non-finite one. This 

69 To be able to quantify over all daughters - as is necessary to collect the nonlocal features in the nonlocal 
feature principle and the quantifiers in the semantics principle - one has to keep track of all daughters in a list 
anyway. However, as discussed in conjunction with the interface specification for the principles, this can be done 
without permanently encoding them using an additional attribute. 

70 Except for the differences commented on in the discussion of examples from the grammar in the previous 
sections, every difference between the linguistic theory and the implemented grammar is discussed below. This 
ensures that the work on the implementation of a theory as test for the rigid, explicit, and correct formalization 
of a linguistic theory can provide feedback for the further development of the linguistic theory. 
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is technically reflected in the following way : The subject of finite verbs are encoded together 
with the internal complements (in attribute SUBCAT), while that of non-finite verbs is specified 
in a separate attribute SUB J. This lexical information is put to work via an id schema which 
realizes all elements in one local tree which are subcategorized for in SUBCAT. A single ID 
schema now suffices to build finite sentences and verb phrases and - since no ID schema ever 
refers to the SUBJ attribute - one explains that only subjects of finite verbs can be realized. 
HN adopt this elegant technique. 72 

From an implementor's point of view the proposal loses at least some of its elegance. As referred 
to in section 4.1, HN propose an argument raising specification as part of the lexical entries of 
auxiliary verbs. Figure 55 shows the basic form of the argument raising specification of HN. 73 



[comps |T|] & append ([TJ, 



SYNSEM|LOC|CAT 



HEAD 


verb 




COMPS 







,0) 



Figure 55: The HN argument raising specification on a non finite auxiliary (valence value and 

relational attachment shown) 



Looking at figure 55, one sees that argument raising introduces a tag in the lexical entry (|T|) 
which in the lexicon is completely unrestricted. The set of objects described by the first argument 
and the result argument of the definite clause append only get narrowed down by the usage of 
the lexical entry in a tree. The HN use of append in the lexical entry of auxiliary verbs therefore 
presupposes a rather sophisticated control mechanism for constraint resolution which executes 
a definite clause at the time its essential arguments are instantiated. Neither ALE nor Troll 
offered such control mechanisms at the time of the implementation. 74 

If the order of the COMPS list is reversed, the usual encoding of lists (in which the first element 
and the rest of a list can be directly accessed) results in an encoding which no longer needs 
the append relation. We can simply structure share the embedded verb's COMPS with the tail 
of the outer COMPS list. This change of the valence list order further reduces complexity by 
eliminating the calls to the definite clauses which were needed in local trees to access the last, 
most oblique element first since those usually get realized first. 

However, ordering the elements on the subcategorization list by decreasing obliqueness (as in 
Pollard and Sag (1987)) is also problematic; again because of the argument raising mechanism. 
To see this, the argument raising specification with inverted comps list (cf. figure 17) is repeated 



n This is the same analysis of finitivization which has already been subject of some discussion to illustrate the 
named disjunction mechanism on pp. 40. Only the difference in constituent structure involved is relevant in the 
following discussion. 

72 Note a minor notational change. HN use a COMPS attribute in the style of chapter 9 of HPSGII instead of 
the SUBCAT attribute used in Pollard (1990). 

73 HN use a functional notation for the append relation in their diagrams. 

74 The delay patterns of CUF are an example for a mechanism which would handle at least these kind of cases 
(cf. Dorre and Dorna (1993)). The newest version of Troll offers a rather sophisticated freeze mechanism as well. 
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as 56 below. 



COMPS 



SYNSEM|LOC|CAT 



HEAD verb 
COMPS \T\ 



□ 



Figure 56: Argument raising specification on a non- finite auxiliary (valence value shown) 



If we try to formulate a lexical rule forming a finite auxiliary in the style of Pollard (1990) on the 
basis of the valence specification in 56, we are stuck with the impossible: trying to add the subject 
as the least oblique element to the end of a list of undetermined length. Even the desperate 
move of putting the subject into the head of the list (which corrupts the theoretically motivated 
obliqueness ordering) is no solution, since then - due to the now in general undetermined position 
of a possibly occurring verbal-complement - we need to separate phrase structure rules for finite 
and non-finite verbs, or for auxiliaries and main verbs. This, however, is exactly which we 
intended to avoid via encoding the subject on COMPS. 

Concerning the implementation and in the light of the problems with an argument raising 
specification using a call to append, it therefore seems to be cleaner to keep the subject encoded 
in SUBJ for non-finite and finite verbs, which allows easy list manipulation with a COMPS list 
ordered by decreasing obliqueness. 

Since under this approach one needs to separately license constructions that realize subjects 
and those that do not, a head- subject- complement ID schema is introduced in the grammar 
to license finite sentences containing subjects. The head- complement ID of the implemented 
grammar therefore only licenses non-finite VPs and finite sentences with extracted subjects. 



5.2 Specifying SLASH sets depending on COMPS lists 

A problem similar to the use of append in the lexical entries of auxiliaries discussed above 
arises from the formulation of the PVP-Topicalization Lexical Rule in HN. In order to relate the 
list-valued COMPS list to a set-valued SLASH list HN attach a relation same-members to the 
lexical rule (cf. figure 19 of HN). The definite clause same-members can only be executed once it 
is clear which constituents have been syntactically realized where. In the terminology of lexical 
rules of meta-relations, the same-members specification therefore only works with unification as 
application criterion. Regarding the computational treatment of lexical rules, it demands that 
the lexical rules be not completely compiled out, but at least partly computed "on demand" 
while building the syntactic tree. Even if this should turn out to be possible 75 such an approach 
would demand a highly sophisticated control structure. 

Since one might want to argue anyway that the embedding constraint on extraction is to be 
captured in syntax, making the value of SLASH a last-in-first-out list store is a possible solution 
to our problem, since it allows us to replace the same-members relation in the PVP extraction 
lexical rule by a simple token-identity constraint. The pragmatic solution chosen for the grammar 
implemented therefore is to change the value of the SLASH attribute to be a list instead of a 
set. The resulting lexical rule was already shown in figure 40 of p. 36. 



The discussion of the lexical rule mechanism in section 4.1.3 suggests that there are some severe theoretical 
and computational problems for such an approach. 



52 



W. DETMAR MEURERS 



5.3 The Cooper-storage mechanism 

In the HPSGII theory a Cooper-storage mechanism is used to calculate all scopings of the 
quantifiers in a sentence. Since this mechanism is integrated into the HPSG setup just like 
the rest of the constraints making up the grammar, in a straightforward implementation all 
scopings of quantifiers will be computed at the same time as the grammatical constraints are 
applied to a local tree. This leads to the same local tree being admitted several times, the only 
difference between the trees being the number of quantifiers retrieved. This is an undesirable 
effect, since these local trees are identical for all syntactic properties that play a role regarding 
the grammaticality of the trees. 

The concept of an underspecified discourse representation defined in Reyle (1993) replaces the 
forced computation of all possible quantifier scopes with a representation of quantifiers under- 
specified for scope. Restrictions on the scope relations can then be formulated on the basis of 
the underspecified representation. This setup avoids an unmotivated multiplication of syntac- 
tic structures while at the same time introducing an elegant mechanism for expressing theories 
about the semantic scope of quantifiers. Frank and Reyle (1992) show that this setup can be 
transferred to HPSG and implemented in an HPSG grammar. 

Since the implementation of HN documented here is concerned with syntactic phenomena only, 
the semantics included in the grammar simply follows the proposals made in HPSGII. How- 
ever, in the semantics principle an additional specification ensures that no quantifiers are ever 
retrieved. Every sentence therefore contains the collection of all its quantifiers in its QSTORE 
attribute as a simple kind of a representation underspecified for quantifier scope. This way we 
obtain a workable setup avoiding the multiple structures with the help of a minor modification. 76 

5.4 Technical comments on the implementation 

The appendix contains the complete ALE grammar including a collection of test sentences for 
all relevant constructions. Additionally the printout of a test run is included to illustrate the 
performance of the grammar in the ALE system. 

5.4.1 The lexicon 

The lexicon of the implementation contains the entries necessary to follow the analyses of aux- 
flip and partial verb phrase topicalization in VI, V2, and VL sentences. As discussed in section 
4.1.2, the implementation contains a hierarchy of lexical macros allowing an easy extension of 
the lexicon. All lexical entries are specified using calls to the lexical macros. 

After lexical rule application, the lexicon contains the following entries: 

Complementizer 

daft (that) 

76 Naturally, the modification of the semantics principle made is not intended to be a theoretical proposal. It 
merely is a loose link between an HPSGII-style semantics and an underspecified representation of quantifiers 
inspired from Reyle (1993) and Frank and Reyle (1992). In any more semantic-oriented grammar fragment that 
link would have to be firmly established. 
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Adjectives 

klein (small), gut (good) 
Determiners 

definite: der (the); indefinite: ein (a), einige (some); negative indefinite: kein (no) 
Nouns 

Mann (man), Tisch (table), Buch (book), Geschichte (story), Verwandter (relative), Karl, Peter, 
Anna, Sarah 

Adjectives, determiners and nouns are included in all possible number, gender, case, and declen- 
sion pattern specifications. 

Main verbs 

intrans: lachen (laugh); trans: lieben (love), finden (find), lesen (read); ditrans: geben (give), 
erzdhlen (tell) 

Auxiliaries 

haben (have), werden (will), konnen (can), miissen (must), wollen (want to) 

Verbs are given in their third person singular and plural, finite, past participle 77 , base forms, 
and (for auxiliaries) the substitute infinitive forms. 

5.4.2 Macros and notational conventions 

Many abbreviations used by HPSG linguists serve to provide easy access to information deeply 
embedded in descriptions. The grammar contains an abbreviation of type sign and one of type 
synsem (which are the types of objects most often talked about in the grammar) for all relevant 
properties. The result is that the descriptions in the implementation often closely resemble the 
specifications in HN. 

Since macros contain descriptions of objects of a specific type, the type of a macro is encoded 
in its name. Suffix "_y" is used for macros of type synsem and macros without suffix are of 
type sign. Those macro names ending in "_lex" are macros of type sign belonging to the lexical 
hierarchy used to specify lexical entries. 

It would be of great value to the user if systems would automatically infer the correct feature path 
at which a specification belongs. For example the description a) below could automatically be 
expanded to that given in b). 

a) word A verb A plusjaux 

u\ SYNSEM|LOC|CAT|HEAD , [ Aux P lus ] 

IJ) I verb 

word 



77 Only past participle formation with "haben" (have) is included. Therefore the past participle of werden is 
not part of the lexicon. 

7S A similar suggestion was made by Jo Calder at the 1st International HPSG Workshop in Columbus, Ohio, 
July /August 93. 
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Clearly some notational conventions (e.g. for the plus-aux case above) and some decisions for 
the search strategy (e.g. shortest path wins) have to be made, but there seem to be no problems 
which render such an extension impossible. Such a notational mechanism would eliminate many 
of the usages of macros and the syntactic errors commonly made by the grammar writer in 
defining those macros. 
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